Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126353
Date: Sat, 08 Feb 2025 15:43:53 +0000
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
Message-ID: <GVZ-MzPMxg2GKWD9aP08gpKTELaGD4M-IwhCNYq5iREXud4dXbcEIG-UrCzx-yECggMCUZNgz0ys59MeOmfi2LpZASeEqCfvyZcoIsDqd08=@gpb.moe>
In-Reply-To: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 7 February 2025 at 04:57, Larry Garfield <larry@garfieldtech.com=
> wrote:

> Hi folks. A few years ago I posted an RFC for a pipe operator, as seen in=
 many other languages. At the time it didn't pass, in no small part because=
 the implementation was a bit shaky and it was right before freeze. Nonethe=
less, there are now even more (bad) user-space implementations in the wild,=
 as it gets brought up frequently in "what do you want in PHP?" threads (th=
ough nowhere near generics or better async, of course), so it seems clear t=
here is demand in the market for it.
>=20
> It is now back with a better implementation (many thanks to Ilija for his=
 help and guidance in that), and it's nowhere close to freeze, so here we g=
o again:
>=20
> https://wiki.php.net/rfc/pipe-operator-v3
>=20
> Of particular note, since the last RFC I have concluded that a compose op=
erator is a necessary complement to a pipe operator. However, it's also goi=
ng to be notably more work, and the two operators don't actually interact a=
t all at the code level, so since people keep saying "Small RFCs!", here's =
a small RFC. :-)

I'm very much in favour of this RFC, it will make writing functional and da=
te pipeline code less cumbersome.
I was curious *how* the blocking of by-ref parameter is done, and was pleas=
antly surprised that it is done at run-time, so "prefer-by-ref" parameters =
work without issues.
This is good motivation for me to go back and push the by-value sort() RFC =
[1] as it uses that mechanism.
I've also submitted a PR [1] to add such a test case.
Probably a good idea to specify this in the RFC.

Best regards,

Gina P. Banyard

[1] https://wiki.php.net/rfc/array-sort-return-array
[2] https://github.com/Crell/php-src/pull/1