Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120093
MIME-Version: 1.0
References: <6b5de716-d769-4f0b-b3e6-5a5a211f035a@app.fastmail.com>
In-Reply-To: <6b5de716-d769-4f0b-b3e6-5a5a211f035a@app.fastmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 20 Apr 2023 17:23:13 -0600
Message-ID: <CAAKU0umCUU=Y04EvqLoFj0wo4QmmRPmR=PZ__rxTfeSYU2sOJw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [Discussion] Callable types via Interfaces
From: internals@lists.php.net ("Levi Morrison via internals")

On Thu, Apr 20, 2023 at 11:25=E2=80=AFAM Larry Garfield <larry@garfieldtech=
.com> wrote:
>
> Hi folks.  This is a pre-discussion, in a sense, before a formal RFC.  Ni=
colas Grekas and I have been kicking around some ideas for how to address t=
he desire for typed callables, and have several overlapping concepts to con=
sider.  Before going down the rabbit hole on any of them we want to gauge t=
he general feeling about the approaches to see what is worth pursuing.
>
> We have three "brain dump" RFCs on this topic, although these are all sti=
ll in super-duper early stages so don't sweat the details in them at this p=
oint.  We just want to discuss the basic concepts, which I have laid out be=
low.
>
> https://wiki.php.net/rfc/allow_casting_closures_into_single-method_interf=
ace_implementations
> https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implem=
ent
> https://wiki.php.net/rfc/structural-typing-for-closures
>
> ## The problem
>
> function takeTwo(callable $c): int
> {
>     return $c(1, 2);
> }
>
> Right now, we have no way to statically enforce that $c is a callable tha=
t takes 2 ints and returns an int.  We can document it, but that's it.
>
> There is one loophole, in that an interface may require an __invoke() met=
hod:
>
> interface TwoInts
> {
>     public function __invoke(int $a, int $b): int;
> }
>
> And then a class may implement TwoInts, and takeTwo() can type against Tw=
oInts.  However, that works only for classes, which are naturally considera=
bly more verbose than a simple closure and represent only a subset of the p=
ossible callable types.
>
> The usual discussion has involved a way to specify a callable type's sign=
ature, like so:
>
> function takeTwo(callable(int $a, int $b): int $c)
> {
>   return $c(1, 2);
> }
>
> But that runs quickly into the problem of verbosity, reusability, and typ=
e aliases, and the discussion usually dies there.
>

I'm going to stop here. Two big things:

 1. I think reducing verbosity can be left for the future. We don't
have to solve that right now.
 2. I think there's another more important reason previous attempts
failed: they will inevitably burden the programmer without type
inference.For the moment, let's assume this signature:

    function takeTwo(callable(int $x, int $y): int $c);

What happens if I pass a short-closure?

    takeTwo(fn ($x, $y) =3D> $x + $y);

I would be annoyed if I had to write the type info, but particularly
the return type.

Today, if I just used a static analysis tool, there's no problem:

    /** @param callable(int $x, int $y): int $c */
    function takeTwo(callable $c);
    takeTwo(fn ($x, $y) =3D> $x + $y);

 3. And another reason they failed: callables are going to want
generic types pretty commonly. Think array_filter, array_map, etc.

So, I think these brain dump RFCs are all focusing on the wrong problems.