[PHP-DEV] [RFC] Pipe Operator (again)

Mailing Lists php.internals
41

Pipe and compose are importantly different operations. I’ve had user-space implementations of both available for years in crell/fp: https://github.com/Crell/fp/blob/master/src/composition.php

I’d love to have a compose operator natively in PHP, too. The RFC for that is already written, just needs code. I hope to formally propose it soon: https://wiki.php.net/rfc/function-composition

Hmm, that’s great, but looks like we are missing something.

  1. Would you propose the RFC to 8.5? I think it should be proposed with the new pipe operator any way
  2. RFC early feedback

There is no big difference in DX with the new operator “+” for closures:

    • operator may be overridden in some extensions and it also may implement __invoke. What’s expected behavior? It will be totally unclear
  • code examples from the rfc: https://3v4l.org/n7UB0 vs https://3v4l.org/tOlft the first approach is better for me because it may be batch-processed / combined / filtered / modified easily. So taking my first message there are not so many changes: https://3v4l.org/ncpEE

Just try to imagine how to work with the composition and how it perfectly works now: https://3v4l.org/ArK2O

By the way, RFC describes userland “compose” function performance problems, but there is no suggestion to make it natively, why so?

···

Dmitrii Derepko.
@xepozz

42

On Tue, Jun 3, 2025, at 2:59 AM, Dmitry Derepko wrote:

Pipe and compose are importantly different operations. I've had user-space implementations of both available for years in crell/fp: fp/src/composition.php at master · Crell/fp · GitHub
I'd love to have a compose operator natively in PHP, too. The RFC for that is already written, just needs code. I hope to formally propose it soon: PHP: rfc:function-composition

Hmm, that's great, but looks like we are missing something.

1. Would you propose the RFC to 8.5? I think it should be proposed with
the new pipe operator any way

I am working with someone on the implementation. As soon as that's done I want to post it. Whether it manages to get into 8.5 at this point is an open question.

2. RFC early feedback

There is no big difference in DX with the new operator "+" for closures:
- + operator may be overridden in some extensions and it also may
implement __invoke. What's expected behavior? It will be totally unclear

I expect the overlap there to be tiny, so it will rarely be encountered. As to which "wins", I'd think probably the extension.

- code examples from the rfc: Online PHP editor | output for n7UB0 vs
Online PHP editor | output for tOlft the first approach is better for me because it
may be batch-processed / combined / filtered / modified easily. So
taking my first message there are not so many changes:
Online PHP editor | output for ncpEE

Just try to imagine how to work with the composition and how it
perfectly works now: https://3v4l.org/ArK2O

If you want to do it that way, Crell/fp has you covered, have fun. But the whole point of the RFC is to provide a native operator for concatenating functions. Decomposing/deconcatenating an already composed function chain is... not a thing.

By the way, RFC describes userland "compose" function performance
problems, but there is no suggestion to make it natively, why so?

Uh. That's the entire point of the RFC? Make a native compose operator that isn't even a function.

--Larry Garfield