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 <andr...@dqxtech.net> 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 <andr...@dqxtech.net> wrote: > > On 10 January 2018 at 19:59, Rasmus Lerdorf <ras...@lerdorf.com> 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 > >
