Re: [Discussion] Revisiting typed closures
| From: | Matheus Martins | Date: | Wed, 01 Jul 2026 20:32:57 +0000 |
| Subject: | Re: [Discussion] Revisiting typed closures | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131678@lists.php.net to get a copy of this message | ||
... so I would start with Closure, not because callable is unwelcome -- the same
signature syntax could extend to it later. Is there a case in your code where
appending (...) would not cover it?
Thanks for your feedback!
On Wed, Jul 1, 2026 at 10:28 PM Matheus Martins <mathrm@gmail.com> wrote:
>
> > I would find this very useful
>
> Glad we agree it brings value.
>
> > That said, restricting it to closures and not any callable is very limiting,
> > particularly now that we have first-class callable syntax.
> > Perhaps something more along the line of: callable(int):bool
>
> I actually read first-class callables the other way -- as what makes
> Closure-only *not* limiting:
strlen(...),
> $obj->method(...) and
> Foo::bar(...)
> all produce a Closure, so any callable can be passed by appending (...).
>
> That is relevant, because this is a runtime check, not a static one. A Closure
> is already resolved -- scope-bound, with its signature on the object, no lookup
> and no side effects. A callable is not: 'foo' resolves against the caller's
> namespace, and [Foo::class, 'bar'] must be resolved and possibly autoloaded
> before its signature is even visible. Enforcing callable(int): bool at a
> boundary would mean doing that resolution -- autoload included -- mid-call,
> which is exactly the surprise I want to keep out of a type check. (callable also
> cannot be a property type today, while Closure can.)