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

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.


Reply via email to