[Vote] Pipe operator v2

Hey Larry,

there's still ongoing discussion on the semantics, and mirroring
implementation defined semantics from the implementation into the RFC
is not the way to go. The RFC should discuss reasons of why semantics
were chosen and the implementation then be decided upon it. Describing
it as "design artifact" is not okay.
I'm voting no at this point, to force it to be postponed to PHP 8.2
with proper thought of what the semantics shall be. Possibly the
semantics are fine (I tend to disagree with the current ones, but
that's rather point for discussion), but they are not discussed enough,
especially as they only got described in the RFC in the last minutes
before the vote.

The semantics around how references work with pipes have been consistent from April 2020 until today, aside from a few hours from when Nikita suggested blocking it to when I determined it was more work than I could handle on short notice. The RFC description of those semantics was clear and accurate for that entire time, modulo those few hours, and there was a test confirming them. So "they only got described in the RFC in the last minutes before the vote" is factually inaccurate.

Wanting to think deeper about how references should work is fine, but please don't misrepresent the situation. How references work in this RFC has been explicitly defined since it was first introduced 15 months ago, and the first pushback on it at all as far as I recall came less than 48 hours before the feature freeze, leaving no time to have such a discussion.

--Larry Garfield

Hey Larry,

I just voted "NO" on this: it took me a long time to decide, because I've
been vouching for pipe-alike operators myself for a while.

The reason why I voted "no" is that this is feasible with a pipe(callable $first, callable ...$piped) function, without having to add syntax/AST for
it.

Type safety for such a closure would still be very messy, but feasible with
some macro-based templating of docblocks.

The simplistic approach to this is simple composition (the . you
mentioned):

/**
 * @template TIn of mixed
 * @template TOut of mixed
 *
 * @param callable(TIn): TIntermediate $first
 * @param callable(TIntermediate): TOut $piped
 *
 * @return callable(TIn): TOut
 * @return TOut
 */
function pipe(callable $first, callable $piped): callable
{
}

Pol Dellaiera (https://github.com/drupol) has done a lot of work around
this stuff, specifically the type inference bit, in
https://github.com/loophp/combinator , so I see hope to get better types at
a later stage.

Therefore:

• userland runtime implementation is trivial
• userland type-safe definition is non-trivial, but not insurmountable

Marco Pivetta

Hi Marco. Thank you for your explanation, even if I naturally disagree.

Out of curiosity, what sort of additional power/capability/flexibility/etc. would, in your mind, justify pipe or similar being a native feature? PHP has a ton of native features that could be done in user space, or are simply syntax sugar, but still wildly popular and useful as native syntax. What is your heuristic for that?

(The fact that there are 3-4 user space implementations of pipe-like behavior, all incompatible, is one of the reasons why I think standardizing it into a common core syntax is a good idea, though I know others disagree.)

--Larry Garfield

Pol Dellaiera (https://github.com/drupol) has done a lot of work around
this stuff, specifically the type inference bit, in
https://github.com/loophp/combinator , so I see hope to get better types at
a later stage.

I don't see a pipe combinator in there, but maybe I can't see it
through the poor formatting of the table... It's been a while since I
delved deep into type theory, but I am not aware of any language which
supports this sort of type safety in functions while being variadic.
Are you aware of any? The only ones I am aware of use macros, which
are different as they are evaluated and expanded at compile time.