RFC
Documentation

Introduces support for constructor property promotion. Initially, I considered adding a new node type for the constructor, but PHP will support using the class name as a constructor name until PHP 9, which makes that difficult/impossible. Thus, the broader support for parsing property promotions even in methods/functions where this is not valid.

Useful facts:

• Not all parameters needs to be promoted
• Promoted parameters may occur anywhere in the parameter list
• A promoted parameter MUST always have a visibility modifier
• Methods with name equal to the class name is a valid (but deprecated) constructor in the global namespace until PHP 9

For consideration:

Simplifications/judgement calls. Let me know if you'd like me to change any of these:

1. Property promotion will never be valid in a function, but only in a method. However, the two share a lot of code in the parser. Thus, I've opted to allow the parsing, but defer the handling of this to any intelligence using the parser.
2. Callable is not a valid type for property promotion. Any handling of this has, for simplicity, been defered to any intelligence using the parser.

New nodes:

• property_promotion_parameter

Example:

class Point {
    public function __construct(
        public float $x = 0.0,
        float $y = 0.0,
        private float $z = 0.0
    ) {}
}

Parses into:

(class_declaration
  name: (name)
  body: (declaration_list
    (method_declaration
      (visibility_modifier)
      name: (name)
      parameters: (formal_parameters
        (property_promotion_parameter
          visibility: (visibility_modifier)
          type: (type_list
            (primitive_type)
          )
          name: (variable_name (name))
          default_value: (float)
        )
        (simple_parameter
          type: (type_list (primitive_type))
          name: (variable_name (name))
          default_value: (float)
        )
        (property_promotion_parameter
          visibility: (visibility_modifier)
          type: (type_list (primitive_type))
          name: (variable_name (name))
          default_value: (float)
        )
      )
      body: (compound_statement)
    )
  )

NOTE: If this adds another method parameter type, thus either this PR or #69 will need adaptation depending on which is merged first.

Checklist:

• All tests pass in CI.
• There are sufficient tests for the new fix/feature (see tests in expressions.txt)
• Grammar rules have not been renamed unless absolutely necessary (0 rules renamed)
• The conflicts section hasn't grown too much (0 new conflicts)
• The parser size hasn't grown too much (master: 1664 , PR: 1672)