Re: [PHP-DEV] [RFC] Primary Constructors

On 30.06.26 23:55, Larry Garfield wrote:
> On Mon, Jun 29, 2026, at 3:56 PM, Nick Sdot wrote:
>
>>>      final readonly class Foo(Collection|array $value) implements Bar {
>>>          $this->items = $value instanceof Collection ? $value : new
>>> Collection($value);
>>>      } => {
>>>          public Collection $items;
>>>
>>>          // class body private Collection $items
>>>      }
>>>
>>>      final readonly class Foo implements Bar {
>>>          public Collection $items;
>>>
>>>          public function __construct(Collection|array $value) {
>>>              $this->items = $value instanceof Collection ? $value : new
>>> Collection($value);
>>>          }
>>>
>>>          // class body private Collection $items
>>>      }
>>>
>>> I find the latter *much* clearer.
>> Great, then you are lucky, because you *can* write it that way. Now
>> allow me too writing it how I want writing it and everyone is happy! <3
>>> Best regards
>>> Tim Düsterhus
>> --
>>
>> Cheers
>> Nick
> (Not sure where in the thread to put this, so just replying to the most recent message.)
>
> It's worth noting that in C# (not sure about the other languages) it's possible to set the default value of a non-promoted property to an expression that includes the primary constructor parameters.  The example from the C# docs[1]
>
> public struct Distance(double dx, double dy)
> {
>      public readonly double Magnitude => Math.Sqrt(dx * dx + dy * dy);
>      public readonly double Direction => Math.Atan2(dy, dx);
> }
>
> Which in PHP would look something like this:
>
> class Distance(float $dx, float $dy)
> {
>      public readonly float $magnitude = sqrt($dx * $dx + $dy * $dy);
>      public readonly float $direction = atan2($dy, $dx);
> }
>
> I'm not saying we should adopt that approach, necessarily.  I'm just noting it as a possible workaround for "i want a primary constructor and a tiny bit of post-processing", if an init block isn't an acceptable.  (I'm not sure how exactly that overlaps with property accessors; maybe it's the same thing?)
>
> It sounds like Nick and Tim are fundamentally split on having an init block (however it's spelled).  I'm impartial.  I can see the use for it, but I also would be OK if it is punted for later.  I'd also be OK with exploring a C#-style approach as above.
>
> As far as size/scope, RFCs should be "self-complete."  They should offer some functionality that is useful on its own, even if it gets multiplied by some other RFC.  Sometimes that means split it up, sometimes it means combine it.  Right-sizing an RFC is not about making it as small as possible or as far-reaching as possible.  So if the result of the discussion is that we do need to double the length of the RFC to include a constructor init block of some kind, so be it.  That's not a bad thing if the result is a better feature.  Nor is leaving it out bad if the result is a better feature.  The goal should be "a complete and robust feature", not big or small chunks.
>
> [1]https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/primary-constructors#create-mutable-state
>
> --Larry Garfield


Thanks, Larry.
I'd like to take the chance to address Rob's "would explode the 
complexity of the RFC", because I honestly don't see it. I keep the 
following examples focused on the parent constructor calling; omitting 
any unrelated noise.


```

final readonly class Dog(
     string $name,
)extends Animal {
     parent::__construct($name);
}=> {
     // class body }

```

The above:
- does NOT have a parent constructor shortcut call -> `extends Animal`
- DOES allow parent constructor call in primary constructor body
- behaves exactly (!) as a conventional constructor; in fact syntax sugar

```

final readonly class Dog(
     string $name,
)extends Animal($name)// already IS the parent constructor call... {
     // hence, here no parent constructor call allowed }=> {
     // class body }

```

The above:
- DOES have a parent constructor shortcut call -> `extends Animal($name)`
- does NOT allow parent constructor call in primary constructor body
- *no difference in parent constructor calling behaviour to what the RFC 
proposes now*

It's easy to reason about with: "either parent constructor OR parent 
constructor shortcut can be called".

It does not need a new name like "init block", it's a constructor body 
on the primary constructor. Which works as any other conventional 
constructor body, because it is syntax sugar. So where is the 
complexity? What would justify not allowing the body that helps to 
address a real problem?

--

Cheers
Nick