Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115456
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-ID: <83bdd8d9-9962-4995-9aff-4bd9b6b7e9b9@www.fastmail.com>
In-Reply-To: 
 <CADyq6sJFmNiVSJPTGnjQOXGMFeezRLUCPbM6rJ3jooAVKPfXxA@mail.gmail.com>
References: <6a2ef792-9624-4355-ad08-dcc7bfa5e19f@www.fastmail.com>
 <CADyq6sJFmNiVSJPTGnjQOXGMFeezRLUCPbM6rJ3jooAVKPfXxA@mail.gmail.com>
Date: Sat, 17 Jul 2021 10:59:52 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [Vote] Pipe operator v2
From: larry@garfieldtech.com ("Larry Garfield")

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