Re: [Vote] Pipe operator v2
| From: | Marco Pivetta | Date: | Sat, 17 Jul 2021 14:48:04 +0000 |
| Subject: | Re: [Vote] Pipe operator v2 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115453@lists.php.net to get a copy of this message | ||
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
http://twitter.com/Ocramius
http://ocramius.github.com/
On Tue, Jul 6, 2021 at 7:13 PM Larry Garfield <larry@garfieldtech.com>
wrote:
> I have opened the vote on the Pipe operator RFC:
>
> https://wiki.php.net/rfc/pipe-operator-v2
>
> The vote will close on 20 July.
>
> --
> Larry Garfield
> larry@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>