Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127035
Precedence: bulk
MIME-Version: 1.0
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
 <CAPyj-LBvmUfhakS+Z9wDYQ-J7Bypk9bbTupPqv-kvfPp8r_qnA@mail.gmail.com>
 <5efa2f02-dd1d-4d59-ae07-c75f193b4096@app.fastmail.com> <92b7f1ea-900b-4438-bed7-3fd766bb2d61@rwec.co.uk>
In-Reply-To: <92b7f1ea-900b-4438-bed7-3fd766bb2d61@rwec.co.uk>
Date: Thu, 3 Apr 2025 19:39:19 +0200
Message-ID: <CAPyj-LDnq3GM3A5hpO4-Cmq3TD3SC1L_29ViQiu1umuF6_jNSA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Rowan

On Thu, Apr 3, 2025 at 1:59=E2=80=AFPM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> At first, I thought Ilija's example looked pretty neat, but having
> thought about it a bit more, I think the "first-arg" approach makes a
> handful of cases nicer at the cost of a lot of magic, and making other
> cases worse.

I think "handful" is the word to focus on. As noted, I believe the
primary use-case for pipes are iterators. If that's true, then an
implicit first-arg approach should cover the majority of examples,
while complicating the rest. Whether that's a worthwhile trade-off is
for the community to decide.

To me, pipes improve readability when they behave like methods, i.e.
they perform some operation on a subject. This resembles Swift's
protocol extensions or Rust's trait default implementations, except
using a different "method" call operator. With this mental model, the
first-arg approach seems intuitive to me. Once parameters are out of
order, the pipe examples with partial function application cause more
cognitive overhead for me, but this is entirely subjective.

> If we have a special case where the right-hand side *is* an expression,
> evaluated as a single-argument callable/Closure, that's even more scope
> for confusion. [cf my thoughts in the async thread about keeping the
> right-hand side of "spawn" consistent]

To clarify: I'm not in favor of this syntax either. While I originally
mentioned it as a possibility, I later noted that `lhs |> {rhs}` would
be less ambiguous, given that {} is not legal in the general
expression context, while also resembling the `lhs->{rhs}` syntax to a
degree. However, because {} is not simpler than `lhs |> rhs()`, I
mentioned neither in my e-mail.

> The cases it makes nicer are where you are chaining existing functions
> with the placeholder as first (but not only) parameter.

If we decide not to add an iterator API that works well with
first-arg, then I agree that this is not the right approach. But if we
do, then neither of your examples are problematic.

> // first-arg chaining
> $someChain |> fn($string) =3D> explode(':', $string)();

As for string functions, I had a quick look through the stubs and
could only find a handful of functions that are not already
subject-first:

* preg_*/mb_ereg*
* mb_split
* explode

Maybe my search was flawed, let me know if there are any that I
missed. explode() specifically usually appears first in a chain (or
deepest in nested calls), which means it could just remain a normal
function call.

$result =3D explode(' ', $str) |> filter(...) |> map(...) |> join(' ');

The iterator API would improve the array_filter() example. Admittedly,
you might not always want to use iterators. A single array_map() would
likely be faster than going through the iterator API. But then again,
single calls aren't chains, so they won't benefit much from pipes to
begin with.

Ilija