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
