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

Hey Tim,

On 30.06.26 04:27, Tim Düsterhus wrote:
> Hi
>
> Am 2026-06-29 22:06, schrieb Nick Sdot:
>> ```
>>
>> final readonly class Foo(Collection|array $value) implementsBar {
>>     $this->items = $value instanceof Collection ? $value : new 
>> Collection($value);
>> }=> {
>>     // class body private Collection $items
>>
>> }
>>
>> ```
>>
>> How is this not easy to reason about? How is this not *less* confusing?
>
> By introducing `=> {` as a new syntactical pattern that we don't 
> currently have and where we would need to figure out whether that 
> pattern would be consistent with existing use of `=>`. My gut feeling 
> is “it isn’t”.
I have literally zero strong opinion on how the syntax must look like; 
as mentioned in my very first answer to Rowan (discussion 1), this is 
meant to illustrate the concept and placement, not syntax.
>
> I'm also noting that your example doesn't declare the `$items` 
> property, which to me is an indicator that it actually isn't that easy 
> to reason about. 

It does declare it; for some reason it just slipped up behind the "class 
body" comment -- which is not the case in my sent mails.
>>> “Reduce typing” alone is not a sufficiently strong argument in favor 
>>> of a new feature.
>>
>> Not sure how reduce typing is related to the argument I am making? My 
>> point is that I *want* primary constructors, but that they should 
>> allow bodies to have the same workarounds at hand to deal with 
>> readonly and hook issues as with conventional constructors.
>
> The stated goal of the RFC (from the introduction) is: “removing […] 
> boilerplate”. It specifically does so by allowing to omit `public 
> function __construct`, `parent::__construct`, and a pair of braces. 
> Personally I don't see much value in “just avoid typing some 
> characters”. However for “logic-less” classes that just store some 
> values, I can see where the proposal is coming from and the guarantee 
> that the constructor actually is “logic-less” is some - small - 
> benefit over “avoid typing characters that your IDE will autocomplete”.
>
> This small benefit would entirely go away by allowing arbitrary logic 
> in the constructor - and then as you said we would “[…] need to find 
> an agreement on how parent constructor stuff works”, which is adding 
> *extra* semantics that folks need to learn onto a feature that is 
> supposed to make things *simpler*.

Quoting myself: "usage of parent constructor shortcut forbids manual 
parent constructor calling, and vice versa. Makes sense to me, and 
sounds easy to reason about."
>
> Staying with your example above, but declaring `$items`, I've come up 
> with the following:
>
>     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