Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114902
MIME-Version: 1.0
References: <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <88588b8f-5729-4458-90b1-c602f751e128@www.fastmail.com> <CAF+90c9EaGreC0y6FagwLn+2OSQUgcQe9UmQdzZaqEYGw0aJbQ@mail.gmail.com>
 <33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com>
In-Reply-To: <33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com>
Date: Wed, 16 Jun 2021 10:16:37 +0200
Message-ID: <CAF+90c_nKeFJMD8zZefCHNEhZyrp9snuKgj8VRxNhwUi8h41Bw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000970a3a05c4ddb683"
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000970a3a05c4ddb683
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 15, 2021 at 6:31 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Tue, Jun 15, 2021, at 10:06 AM, Nikita Popov wrote:
> > On Fri, Jun 11, 2021 at 5:02 PM Larry Garfield <larry@garfieldtech.com>
> > wrote:
> >
> > > On Wed, Mar 3, 2021, at 9:03 AM, Nikita Popov wrote:
> > > > Hi internals,
> > > >
> > > > I would like to propose allowing the use of "new" inside various
> > > > initializer expressions:
> https://wiki.php.net/rfc/new_in_initializers
> > > >
> > > > In particular, this allows specifying object default values for
> > > properties
> > > > and parameters, and allows the use of objects as attribute arguments.
> > > >
> > > > The RFC is narrow in scope in that it only adds support for "new". An
> > > > extension to other call kinds should be straightforward though.
> > > >
> > > > Regards,
> > > > Nikita
> > >
> > > Hi Nikita.  What's the status of this RFC?  Are you going to bring it
> to a
> > > vote, or is something else blocking it?
> > >
> >
> > I've just pushed a larger update to the RFC, which limits the places
> where
> > new is supported.
> >
> > Supported:
> >  * Parameter default values (includes promoted properties)
> >  * Attribute arguments
> >  * Static variable initializers
> >  * Global constant initializers
> >
> > Not supported:
> >  * Static and non-static property initializers
> >  * Class constant initializers
> >
> > I believe the cases that are now supported should be completely
> unambiguous
> > and uncontroversial. The other cases have evaluation order issues in one
> > way or another. This is discussed in
> > https://wiki.php.net/rfc/new_in_initializers#unsupported_positions.
>
> Thanks, Nikita.  I would vote for this as is, but I am saddened by the
> lack of static property initializers.  That's the main use case I am
> interested in.  (In particular, because sealed classes plus
> new-in-static-property would allow for something substantially similar to
> tagged unions, just not built on enums, and the latter is not making it
> into 8.1 it looks like.)
>
> Arguments and attributes are enough to justify this RFC on its own, but is
> there a way we can resolve the static property question?  Right now the RFC
> says "these initializers are evaluated lazily the first time a class is
> used in a certain way."  Can you be more specific about that certain way?
> Is there a certain way that would be minimally disruptive?


Well, here is a non-exhaustive description of current behavior:

 * If you access a class constant, only that constant is evaluated.
 * If you access a static property, all initializers in the class and
parent classes are evaluated.
 * If you instantiate a class, all initializers are evaluated.
 * Inheriting from a class or calling a static method doesn't evaluate
anything.

As you can see, the rules are rather ad-hoc. To the user, it's probably not
obvious why instantiating an object of a class would require evaluating
class constants at that point. The reason is that instantiation requires
resolved property defaults, and we happen to evaluate all initializers at
once.

The options where static properties and class constants are concerned are:

1. Eagerly evaluate initializers on declaration. This is what I tried in an
earlier revision of the RFC, and I don't think that approach works. It
breaks existing code and has various other unpleasant complications.
2. Precisely specify the current behavior. I don't want to do this either,
because the exact places where evaluation happens are something of an
implementation detail. If in the future we find it convenient to separate
evaluation of non-static properties on object instantiation from evaluation
of static properties and class constants (which are not strictly needed at
that point), I'd like to retain the liberty to make such a change.
3. Do not specify an evaluation order, beyond that evaluation happens at
certain uses of the class. Evaluation order may change across PHP versions.
If your code relies on any particular order, your code is broken.

Unless I'm missing a fourth option here, option 3 is the only one I would
be willing to go for at this time.

Also, I think there's a typo in the preceding paragraph about property
> initializers.  It says "the disciplined invocation of such constructors
> from potential parent constructors."  Shouldn't that be potential child
> constructors?
>

Yeah, that's right. Fixed!

Regards,
Nikita

--000000000000970a3a05c4ddb683--