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%
2

I've been waiting for pipe operators in a very long time.

Share:
terremoth avatar
terremoth
voted yes
1

It is awesome.

Share:
geoffreyvanwyk avatar
geoffreyvanwyk
voted yes
1

finally

Share:
luis-engelniederhammer avatar
luis-engelniederha...
voted yes
1

It will introduce new complexities in debugging and error handling and also existing library implementations (e.g., Laravel's pipeline) already offer similar functionality without needing language changes. Instead of achieving the same result with simple code why do we attempt to pollute the current syntax.

$value = 'Hello world';
array_map(static function($fn) use (&$value){
		if(is_callable($fn)){
				$value = $fn($value);
		}
}, [
'htmlentities',
'str_split',
fn($x) => array_map('strtoupper', $x),
fn($x) => array_filter($x, fn($v) => $v != 'O')
]);

var_dump($value);
Share:
erce avatar
erce
voted no
1

Much cleaner than multiple variables or lots of indentation.

Share:
kane-menicou avatar
kane-menicou
voted yes
1
  • less clutter
  • syntax worked for other languages
  • easy understandable
Share:
eugen avatar
eugen
voted yes
1

I like the concept but not the operator. As one of the other commenters said, it would be better if all the scaler

Share:
nathan avatar
nathan
voted yes
1

So much energy invested into some messy code, where not even 'htmlentities' can be found by IDE, as it's a string. Why is the following edge-case (!) not convenient enough?

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

or

$result = strtoupper(htmlentities("Hello World"));
$result = array_filter(str_split($result), fn($v) => $v != 'O');
Share:
mansurs avatar
mansurs
voted no
1
  • This syntax is in my opinion not really an advantage, especially with the hacky way to specify the callbacks (not even/especially not with the first class callable syntax).
  • The argument positions are not consistent enough to support calls like this
  • Passing additional arguments (like limiting the str_split, or specifying flags for htmlentities in the example) is not possible (or either will be really difficult to read, or will require to wrap it in arrow functions).

In classic PHP this is totally fine to read:

$input = 'Hello World';

$encoded = htmlentities($input, double_encode: false);
$list = str_split($encoded);
$uppercased = array_map(strtoupper(...), $list);
$result = array_filter($uppercased, fn($v) => $v !== '0'));
Share:
im-a-teapot avatar
im-a-teapot
voted no
1

We should accept any RFC increasing the capacity of PHP to design things elegantly. Which is done by this suggestion.

I voted "Yes".

PHP misses linear function composition... until now.

Share:
trehinos avatar
trehinos
voted yes
1

I find this syntax pretty messy, to be frank. Maybe it's a good idea (since it is available in "modern languages"), but not something I would use much or even recommend using...

Share:
jhonatanjacinto avatar
jhonatanjacinto
voted no
1

Imagine, having chainable functions like Laravel collections inside php

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

That would be so useful. Not to mention about pipeline pattern, which can be implemented with this, so easy. I do like First-class callable syntax.

Share:
uchm4n avatar
uchm4n
voted yes
1

It would make chaining arguments easier to read, but that it. No good control over the exact output and it is really different from the PHP programming way. For me its more a maybe.

Share:
MarcHagen avatar
MarcHagen
voted yes
1

i think php should have more build in support for functional programming concepts so pipe operator looks like a good idea to me. i do agree that the syntax maybe needs some work.

Share:
gertvdb avatar
gertvdb
voted yes
1
Share:
undjike avatar
undjike
voted yes

Check out another RFCs

Property Hooks

A new way of interacting with properties

70
141 yes
90 no
Interface Default Methods

Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.

95
168 yes
264 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
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!