The Pipe Operator

Read the RFC Externals
93
272 yes
131 no

The "pipe operator" |> allows you to chain multiple function calls in a more convenient way.

$result = "Hello World"
    |> 'htmlentities'
    |> 'str_split'
    |> fn($x) => array_map('strtoupper', $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

This RFC was already declined, but we're sharing it here as another test RFC, and because it'd be interesting to learn people's opinion about it.

Click the bar to cast your vote!
67%
33%
1

Pipes are common in many languages and aren't an unfamiliar concept. Whilst there are packages, like Laravel's pipelines, that implement a way to achieve this, this syntactic sugar makes it easy to implement lightweight code for performing a simple series of actions on a subject.

Share:
sam-moffat avatar
sam-moffat
voted yes
1

You could do this simply enough in userland code

pipe(
		'Hello world',
		htmlentities(...),
		'str_split',
		fn($x) => array_map('strtoupper', $x),
		fn($x) => array_filter($x, fn($v) => $v != 'O'),
);
function pipe(...$pipes) {
    $result = array_shift($pipes);
    foreach ($pipes as $pipe) {
        $result = $pipe($result);
    }

    return $result;
}
Share:
letssurf avatar
letssurf
voted no
1

I do not like this syntax at all and have no problem with user-land solutions.

Share:
eigan avatar
eigan
voted no
1

My chief complaint about the syntax is it blocks functions with multiple parameters. This kneecaps the piping capability, and you're forced back into inside-out calls, or stopping a pipe to call a prohibited function, then start a new pipe with that result.

The operator itself |> is fine, and to me it reads easily as one expression sending a value forward. What i dislike is the representation of the right-side callable: " Hello world " |> 'trim' or "Hello world" |> [$object, 'method'] ... In my opinion, the language already has too much of this workaround syntax.

First-class callable syntax " Hello world " |> trim(...) is helpful in that regard, but still falls apart when multiple arguments are needed.

Share:
thookerov avatar
thookerov
voted no
1

Generally YES, but with some minor change that would allow skipping defining function, so instead of:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

I'd rather see something like

$result = "Hello World"
    |> htmlentities(...) // or htmlentities(?)
    |> str_split(...)
    |> array_map(strtoupper(...), ?)
    |> array_filter(?, fn($v) => $v != 'O');
Share:
jacek avatar
jacek
voted no
1

This looks like a problem that would be better-solved with a first-party object-oriented API for primitive types (a bit like JavaScript). Honestly the syntax looks a bit odd and as per the example, referencing global functions as strings is an anti-pattern IMO (not friendly for IDEs / refactoring!).

For example:

$result = ("Hello World") // string
    ->htmlentities(...)
    ->split(...) // array
    ->map(fn ($x) => strtoupper($x))
    ->filter(fn($v) => $v != 'O');
Share:
uphlewis avatar
uphlewis
voted no
1

It's nice to have.

Share:
stanislav-janu avatar
stanislav-janu
voted yes
1

I don't see any advantages and the syntax is a mess.

Share:
uli avatar
uli
voted no
1

functions as strings? Bro no way

Share:
pimjansen avatar
pimjansen
voted no
1

Improves readabillity drastically

Share:
aradoje avatar
aradoje
voted yes
1

Neat with first class callable syntax

Share:
sandermuller avatar
sandermuller
voted yes
1

It makes chain calls easier

Share:
maureis avatar
maureis
voted yes
1

First, it's really mostly syntactic sugar, adding cognitive load for no added Language-level feature. Besides, it's not clear how easy it would be to step over this code with a debugger.

Second, the argument that the equivalent nested function calls is much less readable, is sound but I think a developer should write neither. Both nested functions calls and chained function calls are hard to live-debug and hard to read, and most of the time in my experience are also an unnecessary micro-optimization.

Third, I think this specific operator "|>" isn't easy to type. The "->" member operator was a mistake of the past, we are stuck with it, don't make another one.

Share:
agc avatar
agc
voted no
1

Makes code more readable because has the natural direction of reading (if reading left-to-right, of course)

Share:
daviscaics avatar
daviscaics
voted yes
1

There is a chain of responsibilities patter that does exactly the same, so I don't see any reason to implement this.

Share:
piotrfilipek avatar
piotrfilipek
voted no

Check out another RFCs

new MyClass()->method() without parentheses

Chain method on newly created objects without parentheses

54
95 yes
16 no
Short Closures 2.0

This RFC proposes a way to have multi-line short closures — closures that don't need explicit use statements, but can still have multiple lines and a return statement.

101
373 yes
66 no
Asymmetric Visibility v2

A new syntax for declaring the “set” operation visibility of an object property

21
21 yes
38 no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!