Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128148
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 20 Jul 2025 14:20:09 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <ffe776de-203a-4b73-a4c1-28349a700c28@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LAWZnQVV-DzE8yspTMGSQv796CGhMS_SU7HQDwM6W9a1A@mail.gmail.com>
References: <2e8a8375-62ec-4bb2-86ed-7432f389e683@gmail.com>
 <CAPyj-LAWZnQVV-DzE8yspTMGSQv796CGhMS_SU7HQDwM6W9a1A@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal. Pipeline assignment operator
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jul 20, 2025, at 5:22 AM, Ilija Tovilo wrote:
> Hi Vadim
>
> Thanks for your follow-up.
>
> On Sun, Jul 20, 2025 at 11:54=E2=80=AFAM Vadim Dvorovenko
> <vadim.dvorovenko@gmail.com> wrote:
>>
>> Recently introduced pipeline operator is great, but together with
>> assignment operator it will lead to mixing top-to-bottom and
>> bottom-to-top code reading directions and vertigo.
>>
>> To reduce this problem i'd like to discuss the idea of left to right
>> assignment operator. The draft rfc can be found here
>> https://github.com/vadimonus/php-rfc-pipeline-assignment/blob/main/rf=
c.md
>> , there is the part, that describes problem.
>
> The problem you're describing is not unique to pipes. Code like this
> is quite common.
>
> $x =3D foo()
>     ->bar()
>     ->baz();
>
> If we decide this is a problem (which I fundamentally disagree with),
> then we should try to find a general solution, rather than something
> that is specific to pipes. There's no reason why this example
> shouldn't work.
>
> foo()
>     ->bar()
>     ->baz() |>=3D $x;
>
> At that point, you should probably also look for an operator that
> isn't pipe-specific. But again, I disagree with the premise that this
> is a problem to begin with.
>
>> The current bahavior of pipe operator when used with variable is wery=
 poorly described in RFC
>
> That's not quite accurate. It states:
>
>> The left-hand side of the pipe may be any value or expression.
>
> And according to PHPs expression model, variables get no special
> treatment. They are evaluated and the result is used accordingly,
> pipes are not special at all in that regard.
>
> Cheers
> Ilija

I am also not a fan of this proposal for much the same reason.

First, the mental model it proposes I do not agree with.  The model of=20

<variable to assign to> =3D <arbitrarily complex expression>

is fairly universal in PHP and in most languages.  It's quite self evide=
nt at this point. =20

Furthermore, there are plenty of other "read down and up" use cases beyo=
nd pipe.  match() and ternaries come to mind as common examples.

The behavior of pipes with variables is also very well defined.  The lef=
t side is any expression (including a variable).  The right side is a ca=
llable.  That callable could be a variable that references a Closure, an=
d often will be.  So it's already quite clear what will happen

If we were to agree that there was a use case for "reverse assignment" (=
of which I am not yet convinced), it should be its own stand-alone thing=
.  Just for argument's sake (not actually proposing this):

<expression> =3D=3D> <variable to assign to>

That would then work at the end of a pipe chain, a match statement, a te=
rnary, or whatever else you felt like.  Self-contained parts that play w=
ell with others are almost always superior to a one-off solution.

--Larry Garfield