Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114891
User-Agent: Cyrus-JMAP/3.5.0-alpha0-519-g27a961944e-fm-20210531.001-g27a96194
Mime-Version: 1.0
Message-ID: <33fd3541-8518-4f98-a258-705f85180ed1@www.fastmail.com>
In-Reply-To: 
 <CAF+90c9EaGreC0y6FagwLn+2OSQUgcQe9UmQdzZaqEYGw0aJbQ@mail.gmail.com>
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>
Date: Tue, 15 Jun 2021 11:30:20 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: larry@garfieldtech.com ("Larry Garfield")

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?

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?

--Larry Garfield