Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115305
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-ID: <48bc0d19-ba92-4dbf-b2d4-a32688ed4e25@www.fastmail.com>
In-Reply-To: <63aa426c-30bc-4f00-8740-532fa0bef6f2@www.fastmail.com>
References: <d50eaa78-21c7-46e7-9da6-629ba5694d3f@www.fastmail.com>
 <63aa426c-30bc-4f00-8740-532fa0bef6f2@www.fastmail.com>
Date: Mon, 05 Jul 2021 11:05:36 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Pipe Operator, take 2
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote:
> On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote:
> > Hi folks. Me again.
> > 
> > A year ago, I posted an RFC for a pipe operator, |>, aka function 
> > concatenation.  At the time, the main thrust of the feedback was "cool, 
> > like, but we need partial function application first so that the syntax 
> > for callables isn't so crappy."
> > 
> > The PFA RFC is winding down now and is looking quite good, so it's time 
> > to revisit pipes.
> > 
> > https://wiki.php.net/rfc/pipe-operator-v2
> > 
> > Nothing radical has changed in the proposal since last year.  I have 
> > updated it against the latest master.  I also updated the RFC to use 
> > more examples that assume PFA, as the result is legit much nicer.  i 
> > also tested it locally with a combined partials-and-pipes branch to 
> > make sure they play nicely together, and they do.  (Yay!)  Assuming PFA 
> > passes I will include those tests in the pipes branch before this one 
> > goes to a vote.
> 
> Hi again.
> 
> With PFA being declined, I've again reworked the Pipes RFC.
> 
> 1) It now does not use PFA in any examples, but it does use Nikita's 
> first-class-callables RFC that looks like it's going to pass easily.
> 
> 2) With major hand-holding from Levi Morrison and Joe Watkins, the 
> implementation has shifted a bit.  It now evaluates left-to-right, 
> always, whereas the previous version evaluated right-to-left.  That is, 
> instead of $a |> $b |> $c desugaring into $c($b($a)), it now becomes 
> effectively $tmp = $a; $tmp = $b($tmp); $tmp = $c($tmp);  That matters 
> if $b or $c are function calls that return a callable, as they are then 
> only called when the pipeline gets to that part of the expression.  (If 
> all the functions involved are pure functions, then it doesn't make a 
> difference in practice.)
> 
> 3) I included references to several existing PHP libraries that 
> implement similar logic, in mostly complex and ugly ways.
> 
> 4) Of note, Brent posted a Twitter poll last week about pipes, and the 
> response was overwhelmingly in favor.  
> (https://twitter.com/brendt_gd/status/1408271132650885123)  Naturally a 
> Twitter poll is extremely unscientific, but I think between the 
> existing libraries and the response there the answer to the question 
> "is there actually a demand for this feature?" is unquestionably yes.
> 
> 5) Examples have been reworked to be a bit prettier.
> 
> 6) Added another language reference that has a pipe operator that works 
> basically like described here. (OCaml)
> 
> I am planning to take this version of the RFC to a vote on Monday or 
> Tuesday, as Tuesday is the last day possible to start a vote for 8.1 
> features.
> 
> --Larry Garfield

Based on feedback on the PR, I've updated the RFC to forbid functions that pass or return by reference.  They're not really useful in pipes at all, and were only supported before because the implementation happened to allow it.

The PR hasn't been updated for that yet, but I figure that's easy enough to update post-vote if it passes.

--Larry Garfield