On Sat, Jul 17, 2021, at 9:48 AM, Marco Pivetta wrote:
> 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):
>
> ```php
> /**
> * @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
