Allow optional promoted class properties to come before required

[syranide]

Description

For normal functions and classes, it largely makes sense to disallow putting optional parameters in-front of required ones. PHP now support named arguments, which means it wouldn't be entirely nonsensical to allow optional parameters in any order, but the use-case seems extremely niche and it seems PHP has explicitly chosen to not support this.

// Emits "Deprecated: Optional parameter $a declared before required parameter $b is implicitly treated as a required parameter"
function f(string $a = "x", $b) {}

However, promoted class parameters/properties seems to intentionally diverge a bit from the normal parameter behaviors (see #11488), at least in-terms of legacy behavior.

// Valid
class PersonA {
  public string|null $name = null,
  public string $email,
}

// Not valid (want this to be valid)
class PersonB {
  public function __construct(
    public string|null $name = null,
    public string $email,
  ) {}
}

PersonA is a completely valid way to specify a class, with the optional property in-front of the required one, and one could argue there is value in manual explicit ordering of properties in this way. However, when using the constructor syntax with promoted parameters (e.g. public in-front of the parameter), this is no longer allowed and optional parameters must come last. Which makes sense when the constructor is viewed as just another function/method.

However, defining plain classes in this way (PersonB) is very useful to emulate the benefits of plain structs due to the support for named arguments, while also guaranteeing that there can be no partial objects of the type (which non-constructor classes fundamentally have to allow). So you get immediate errors if you forget an argument, rather than at some point later when the corresponding property is attempted to be accessed. Using such plain classes/structs explicitly with named arguments makes sense in a lot of cases for representing data, because the ordering of the parameters isn't very informative and/or there may be changes to the property list over time which makes it very fragile to rely on order.

My feature request is that the enforced required-optional ordering is ignored for class constructor parameters that are promoted to properties, so that PersonB above is allowed as an alternative to PersonA, such that we can get the benefits of the constructor for validation and named parameters, without being subject to the forced limitations that apply to parameter ordering of normal functions.

Preferably I would want actual "struct" support, but this seems like a very close approximation for virtually no cost and negative side-effects. Or if you feel that there are unacceptable side-effects of this, maybe there could be an attribute that is used to explicitly disable it instead?

[KapitanOczywisty]

Constructructor property promotion is only syntax-sugar, meaning your example under the hood is treated as:

class PersonB {
  public string|null $name,
  public string $email,
  public function __construct(
    string|null $name = null,
    string $email,
  ) {
    $this->name = $name;
    $this->email = $email;
  }
}

Also note that default value is used for function argument not property itself, and this have some side-effects e.g. when object is unserialized.

Using such plain classes/structs explicitly with named arguments makes sense in a lot of cases for representing data

If you're using named arguments anyway, you can easily put optional after required.

Please do not create more issues around the same problem, this creates a lot of confusion. Such change would also require RFC or at least discussion on mailing list, read more about RFC process.

[syranide]

Constructructor property promotion is only syntax-sugar, meaning your example under the hood is treated as:

This sugar is extremely useful for making it feasible to use in practice though. Without it, representing "structs" is either incredibly verbose/error-prone, or requires a much less flexible and more fragile syntax (i.e. regular object creation). Strongly typed structs with validation (constructor) is hugely valuable in the work I do.

Also note that default value is used for function argument not property itself, and this have some #11354 e.g. when object is unserialized.

Yep, I'm aware of this and it's not a problem for our situation, but it is a weird quirk in how it's desugared, indeed.

If you're using named arguments anyway, you can easily put optional after required.

Ofc, but it is natural for people to want to order properties in a certain way and there is an artificial limitation here that could be valuable to relax for this specific case (since it already seems to have slightly different rule). But indeed it's not a blocker, just a convenience/preference people expect with structs.

But I hear you, and if it requires a longer RFC-process then it's not worth the headache to pursue for me at least. And I see that there's been quite a few struct-RFCs before that hasn't progressed anywhere. Which is what I would want more than anything, but the current promoted property class syntax goes a very long way.

[iluuu1994]

Normally, the non-nullable properties/parameters would be the "important" ones, e.g. name. I understand there are may be exceptions to this, but enough to warrant this change? In any case, this is a language change, if you'd like to start a discussion to see if other people are interested in this, you can start by getting an initial feel on the internals mailing list (step 1 on https://wiki.php.net/rfc/howto). Thank you for your suggestion!