On Tue, Jun 15, 2021 at 6:31 PM Larry Garfield <la...@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 <la...@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
