On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris <tendo...@gmail.com> wrote:
> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf <ras...@lerdorf.com> > wrote: > > > If you stay away from trying to change a 25-year old loosely typed > > language into a strictly typed one, then the RFC becomes much simpler. > > > > -Rasmus > > > > I have REPEATEDLY stated that is not the goal. I don't misrepresent what > you say, please do not do that to me. > > I want to see strict typing as an option, not a requirement. > But the point is that whether it is an option or not, it still has to touch the zval. Which means everything changes whether the option is enabled or not. If you store this information elsewhere, that other location has to be checked on every zval access. Basically the work is identical to the work required to make PHP strictly typed. Making it optional might actually be harder because we have to build both and add more checks in that case. The only viable place I see to store this optionally is outside the runtime in a static analyzer like Phan (which already does this) which matches how HHVM solved it. Of course, there may be a cleaner way to do it. But that is why an RFC on this topic has to give a clear plan towards this cleaner implementation. 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. -Rasmus
