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

Hey Tim,

On 30.06.26 03:37, Tim Düsterhus wrote:
> Hi
>
> Am 2026-06-29 21:20, schrieb Nick Sdot:
>> Well, this is going to be more of a general thing, nothing exclusive 
>> to your RFC... But this is how we end up with more and more half 
>> finished and awkward (to not say broken) features in PHP. While I 
>> understand and generally support "get the minimum in and iterate 
>> later" from the perspective of RFC authors, reality shows that 
>> "later" can be either years later or very likely never at all. 
>> Though, we will have to deal with the unfinished/broken "minimum" 
>> solutions. How many more of these do we want to add?
>>
>> To name three from the top of my mind:
>> 1/ we still don't have stringable enums
>> 2/ we still don't have a solution for widening the type of a promoted 
>> property's set hooks (hi #16638), and of course
>> 3/ my beloved readonly hooks themselves. ;)
>
> I consider (1) and (3) to be fundamentally wrong from a semantic 
> perspective, i.e. a “Won’t fix”, not a missing feature.
>
> For (2) I agree that the situation is unfortunate, but as you say:
>
>> […] See my comment to #16638; we probably should just have skipped 
>> hooks on promoted properties unless there would have been a solution 
>> before release.
>
> … here the correct fix would've been making the feature *smaller* 
> rather than *larger*, which is the opposite of what you are proposing 
> here.
> And for this RFC I agree with Rob that not allowing an explicit body 
> with “primary constructors” is the correct choice to prevent 
> confusion: The limitations are a feature that makes classes using 
> “Primary Constructors” easy to reason about. “Reduce typing” alone is 
> not a sufficiently strong argument in favor of a new feature. As an 
> example, promoted properties are not just “fewer characters to type”, 
> but have the added benefit of “keeping data types in sync between 
> parameter and property”, thus reducing mistakes. I don't see such a 
> benefit for primary constructors if they are capable of doing 
> everything a regular constructor can.

Yes, as I proposed back then. However, I disagree. Making it "smaller" 
is not always automatically the solution. Here it is making it bigger. 
Because making it bigger makes primary constructor behave the same way 
as conventional constructors (with the benefit to be in the class 
header, which I find awesome). I don't see why I should not be allowed 
to write something like this:


```

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? 
It offers the same functionality as a normal constructor. It also would 
not prevent parent class constructor shortcuts or whatever. It in fact 
would not change/remove anything the RFC wants, and it is purely 
additive. If my understanding of Rob is correct, we just would need to 
find an agreement on how parent constructor stuff works.

> “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.
> Best regards
> Tim Düsterhus
--

Cheers
Nick