... 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 <[email protected]> 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.)
