Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101597 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96020 invoked from network); 10 Jan 2018 21:10:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jan 2018 21:10:54 -0000 Authentication-Results: pb1.pair.com header.from=ryan.jentzsch@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ryan.jentzsch@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.172 as permitted sender) X-PHP-List-Original-Sender: ryan.jentzsch@gmail.com X-Host-Fingerprint: 209.85.223.172 mail-io0-f172.google.com Received: from [209.85.223.172] ([209.85.223.172:38250] helo=mail-io0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 66/F9-39025-D51865A5 for ; Wed, 10 Jan 2018 16:10:53 -0500 Received: by mail-io0-f172.google.com with SMTP id d11so939331iog.5 for ; Wed, 10 Jan 2018 13:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G95bUrz2xN3Gvo5LhgPGKazJYMxHjj3pL8FIuDfTms4=; b=Tt+oT7Zfj+zxTXKq0mbcs/H1Jqr7yG4YTS4kB7LSXsq5k2pyjehzvNAeOnY8UceyzO pyt323ExVvAsAFsrKmFO9kHVX3ao6yag00zN4pLNhB0H4zReZp5No9rbVP/U5AcFkuWu HNWM3VZWZALV5xdGmtMD5WZXIyIKIzvIEIASj+uwc0eSZ9WRzdVmaaELaj9vGSy7IzlM Z8L5TAUL1AQXej7ERzZtf4BfjmaTfzGvFvI4/U6pe9AUrGHexngWaVRkBibD3AD1J/ds V2F5F0rrIXJk5zreHg/bHie1r5+UrUCY99W9g5FNKBQjFfKFjzB+oUAYRAKg30QJNOcf O/dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G95bUrz2xN3Gvo5LhgPGKazJYMxHjj3pL8FIuDfTms4=; b=kIvWvig4bqcQKDjHgFBjZUsdUnu1To1peam6FUEB/EOid34Y3ciNKOvBkataokrQSC /ELOwWzSi900aw6i/UKgVWLKtLtrkPp4Dqam4tekphYKtUK2p7iRySR7FzXm40QcyZLy VQgvx8qqNXX/Hzv71LRwQs9JQz8DIB/voz+9lQ5FGk4TNkk2akuYYxiZ2jzauXUS3XuV ZirnlUBahlxyrYIujMw6AP5vpXhEulm6tWyNazEFMO2sL0qEqRAh06RRY16hk7eyu98p oRhZklA8wr9xyL7qWL+38BSLL+hFvuagC/0QzTQiNlquJRo7WjY6+ZKbjeKCnWZUIftV kWWA== X-Gm-Message-State: AKwxytdDLdKFe9LgHrsnjGxO4X/DrnyfPXP9Z9PbYOCkMW70S6pwFgAr wYX686gwZ+XFV39Os/h0X+Ooxv/ra6Cy5OUbR+O3rg== X-Google-Smtp-Source: ACJfBovwZI2ODUl3KCdkyxIDZwrzwfS/byWoy6hsGR7lnCBc4NAYthKjdLc3FddwFwtMuHucKUChfDHiCVpp8hwNoLY= X-Received: by 10.107.142.13 with SMTP id q13mr19831006iod.295.1515618650956; Wed, 10 Jan 2018 13:10:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.3.11 with HTTP; Wed, 10 Jan 2018 13:10:20 -0800 (PST) In-Reply-To: References: <9a3a8760-f65a-a5c0-b318-1830a9a986c3@gmail.com> <9352F6DF-9940-49A2-9B1D-FA9258E9738E@lerdorf.com> Date: Wed, 10 Jan 2018 14:10:20 -0700 Message-ID: To: Andreas Hennings Cc: Rasmus Lerdorf , Michael Morris , PHP internals Content-Type: multipart/alternative; boundary="94eb2c05c5ec4e3e2c05627277ef" Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax From: ryan.jentzsch@gmail.com (Ryan Jentzsch) --94eb2c05c5ec4e3e2c05627277ef Content-Type: text/plain; charset="UTF-8" In my opinion The Strong Typing Syntax RFC will have less of a chance of passing a vote than https://wiki.php.net/rfc/typed-properties. Since the typed-properties RFC was confined to properties on a class (and looking at the code it appears to me that it wasn't too difficult to implement the type strictness constraints). Sadly, even after it was shown to have minimal effect on performance the RFC was still shot down. Strong Typing Syntax I would think is even more complicated given this touches ALL zval processing internally. The concern of "expensive run-time checks" can of course be mitigated by requiring declare(strict_types=1) to enable/allow strong typing syntax. I'd love to see Strong Typing Syntax in PHP but realistically, given the past history, this RFC will need to target version 8. On Wed, Jan 10, 2018 at 12:25 PM, Andreas Hennings wrote: > Whether we work with runtime type checks or compile-time static analysis: > The user-facing language design questions would still be the same, right? > E.g. we would still have to distinguish type-locked parameter values > vs dynamically typed parameter values. > > On 10 January 2018 at 20:23, Andreas Hennings wrote: > > On 10 January 2018 at 19:59, Rasmus Lerdorf wrote: > >> > >> Now if the RFC was a plan for baking a compile-time static analysis > engine > >> into PHP itself, that would be interesting. But that is a *massive* > project. > > > > Even with my limited understanding of the engine, I can imagine this > > to be a lot of work. > > But it sounds much better to me than adding more expensive runtime type > checks. > > I think it would be worth exploring as a long-term direction. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --94eb2c05c5ec4e3e2c05627277ef--