Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [Discussion] Revisiting typed closures »

[Discussion] Revisiting typed closures

php.internals

Matheus Martins

62 days ago
Hello internals, I would like to revisit the idea of giving closures a typed call signature. e.g. Closure(int, string): array -- enforced at the point a value crosses a type boundary (an argument, a return, a property), the same places any other type is checked. Today a closure can only be typed as Closure or callable, neither of which says anything about its parameters or return, even though that information is right there. I know this is not new ground: Callable Prototypes was declined in 2016, and Garfield and Grekas shared two further RFCs in 2023 -- Structural Typing for Closures, and Allow Closures to Declare Interfaces they Implement -- both still in draft. Before taking it further, I would like to know whether closure typing is still considered worth pursuing -- or whether the topic is now regarded as settled. References: - https://wiki.php.net/rfc/callable-types - https://wiki.php.net/rfc/structural-typing-for-closures - https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement Thanks.

Joe Watkins

62 days ago
There was also this: https://wiki.php.net/rfc/functional-interfaces A re-reading of the very brief thread, shows Dmitry thought it an inelegant use/abuse of the type system, and more generally there was a feeling that anon classes could be used in their place. Cheers Joe On Wed, 1 Jul 2026, 16:44 Matheus Martins, <mathrm@gmail.com> wrote:

Rob Landers

62 days ago
On Wed, Jul 1, 2026, at 16:42, Matheus Martins wrote:
> Hello internals, > > I would like to revisit the idea of giving closures a typed call signature. > > e.g. Closure(int, string): array -- enforced at the point a value crosses a > type boundary (an argument, a return, a property), the same places any other > type is checked. > > Today a closure can only be typed as Closure or callable, neither of which > says anything about its parameters or return, even though that information is > right there. > > I know this is not new ground: Callable Prototypes was declined in 2016, and > Garfield and Grekas shared two further RFCs in 2023 -- Structural Typing for > Closures, and Allow Closures to Declare Interfaces they Implement -- both still > in draft. > > Before taking it further, I would like to know whether closure typing > is still considered worth pursuing -- or whether the topic is now regarded as > settled. > > References: > > - https://wiki.php.net/rfc/callable-types > - https://wiki.php.net/rfc/structural-typing-for-closures > - https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement > > Thanks. >
I would rather wait for generics and possibly make Closure a generic type. — Rob

Matheus Martins

62 days ago
> I would rather wait for generics and possibly make Closure a generic type.
Fair point, but I am worried that's misleading, and I would keep the two separate. Generics are a much larger and more contentious topic; typed closure is a much smaller topic: a runtime shape check on a Closure value at the boundary, nothing more. The concrete benefit is typing the callback a higher-order method takes, so a mismatched map/filter callback is caught at the call site rather than deep inside the operation (or only by static analysis): ```php // expected signature: (int) => bool public function filter(Closure(int): bool $pred): static; // ok $nums->filter(fn(int $n): bool => $n % 2 === 0); // TypeError: string not expected $nums->filter(fn(string $s): bool => $s !== ''); ``` Typed closures neither need generics nor blocks them. In fact, eventually typed closures will support generics. But I would rather keep these topics separate. On its own, is a runtime-checked closure signature something you would find useful?

Matthew Weier O'Phinney

62 days ago
On Wed, Jul 1, 2026, 12:11 PM Matheus Martins <mathrm@gmail.com> wrote:
> > I would rather wait for generics and possibly make Closure a generic > type. > > Fair point, but I am worried that's misleading, and I would keep the two > separate. > > Generics are a much larger and more contentious topic; typed closure is a > much > smaller topic: a runtime shape check on a Closure value at the boundary, > nothing > more. > > The concrete benefit is typing the callback a higher-order method takes, > so a mismatched map/filter callback is caught at the call site rather than > deep > inside the operation (or only by static analysis): > > ```php > // expected signature: (int) => bool > public function filter(Closure(int): bool $pred): static; > > // ok > $nums->filter(fn(int $n): bool => $n % 2 === 0); > > // TypeError: string not expected > $nums->filter(fn(string $s): bool => $s !== ''); > ``` > > Typed closures neither need generics nor blocks them. In fact, eventually > typed > closures will support generics. But I would rather keep these topics > separate. > > On its own, is a runtime-checked closure signature something you would find > useful? >
I would find this very useful. 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 This would give more flexibility, and provide us contract guarantees. Right now, SA can validate these, but only via annotations.
-- Matthew Weier O'Phinney mweierophinney@gmail.com https://mwop.net/ he/him

Matheus Martins

61 days ago
> 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.)

Matheus Martins

61 days ago
... 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:

Seifeddine Gmati

61 days ago
> I would rather wait for generics and possibly make Closure a generic type. > > — Rob
Hi Rob, I don't think generics help here. PHP doesn't have generics at all yet, and realistically they're at least a couple of years away. But even once they land, they wouldn't solve this. Making `Closure` generic (e.g., say `Closure<Input, Output>` ) would require `Input` to be variadic to stand in for a closure's parameter list, and variadic generics are a different beast entirely. They've never appeared in any proposal, they don't really make sense for a number of reasons, and if they were ever added at all, it would be years after generics themselves. So "wait for generics" here effectively means waiting indefinitely. And arity aside, a generic `Closure<...>` still couldn't express which arguments are required versus optional, nor type a closure that is itself generic. A dedicated syntax like `fn<T>(T, string=): T` handles all of it cleanly: - The generic parameter ( `<T>` ) - Te required and optional arguments ( `=` marker ) - The return type ( following `:` ) Cheers, Seifeddine

Rowan Tommins [IMSoP]

61 days ago
On 1 July 2026 20:02:27 BST, Seifeddine Gmati <azjezz@carthage.software> wrote:
>Making `Closure` generic (e.g., say `Closure<Input, Output>` ) would >require `Input` to be variadic to stand in for a closure's parameter >list, and variadic generics are a different beast entirely.
FWIW, C# has a long list of overloads for expressing generic lambda types, like Action<T1,T2>, Action<T1,T2,T3>, Func<T1,T2,TResult> and so on and on and on <https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.Private.CoreLib/src/System/Action.cs> <https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.Private.CoreLib/src/System/Function.cs> Ugly, and unlikely to even work in a PHP implementation of generics. On the other hand, it has an elegant "delegate" syntax for what are effectively named callable types: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/delegates/ That *would* translate well to PHP. Translating one of their examples: delegate ProcessBookCallback(Book $book): void; public function processPaperbackBooks(ProcessBookCallback $processBook): void { foreach ($this->list as $b) { if ($b->paperback) { $processBook($b); } } } Just an additional angle to throw into the mix. Rowan Tommins [IMSoP]

Larry Garfield

60 days ago
On Wed, Jul 1, 2026, at 5:02 PM, Rowan Tommins [IMSoP] wrote:
> On 1 July 2026 20:02:27 BST, Seifeddine Gmati <azjezz@carthage.software> wrote: >>Making `Closure` generic (e.g., say `Closure<Input, Output>` ) would >>require `Input` to be variadic to stand in for a closure's parameter >>list, and variadic generics are a different beast entirely. > > FWIW, C# has a long list of overloads for expressing generic lambda > types, like Action<T1,T2>, Action<T1,T2,T3>, Func<T1,T2,TResult> and so > on and on and on > <https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.Private.CoreLib/src/System/Action.cs> > <https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.Private.CoreLib/src/System/Function.cs> > > Ugly, and unlikely to even work in a PHP implementation of generics. > > On the other hand, it has an elegant "delegate" syntax for what are > effectively named callable types: > https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/delegates/ > > That *would* translate well to PHP. Translating one of their examples: > > delegate ProcessBookCallback(Book $book): void; > > public function processPaperbackBooks(ProcessBookCallback $processBook): void { > foreach ($this->list as $b) { > if ($b->paperback) { > $processBook($b); > } > } > } > > Just an additional angle to throw into the mix. > > > Rowan Tommins > [IMSoP]
I am very much in favor of callable types, in concept. (Which should surprise no one.) I don't have very strong feelings on the spelling at the moment yet; I suspect this is a case where the parser will dictate to us what is possible, and that will greatly limit our options or just make the decision for us. (That's how we ended up with fn() for short-closures. It was the shortest thing the parser would let us get away with.) On the question of callable-vs-closure, I agree that today, between FCC and PFA a Closure is absolutely trivial to produce, so we don't need to support the variety of legacy callable formats. The one caveat to that is for compiled code; you cannot store a closure in a serialized form or in generated code; functions and static methods are easy enough to store that way (as a string and array, respectively), ugly as those formats are. Methods, anon functions, etc. however are much harder, and there's no globally standard way of cheating there. I suspect the best we can do without scope creeping ourselves to death is just support closures and leave it to implementers to turn other callable formats into a closure, which isn't that hard these days. Generics syntax is the wrong format to use for this, full stop. Let's not even go down that pathway. Generics are orthogonal. The main semantic question is whether callable/closure types should be defineable inline, or only as a reference (as in Rowan's C# example above.) In the past, there's been non-small pushback to defining them inline, as that can make for very hard to read function declarations and if the same signature is used in multiple places, you have to manually keep them in sync. However, we don't have type aliases (yet), which would resolve that issue. And when proposals have been floated to allow separate definition of a function interface (as Nicolas and I proposed), it's been rejected as too complicated. So we're really at an impasse on this. My own stance is that we should just define them inline for now, and if that leads to messy function signatures then that's just all the more impetus for us to get off our butts and decide on a way to do type aliases. :-) That's better than having a one-off syntax for function signature definition but something entirely different for complex union/intersection types, or restricted types (like "positive int"), etc. Let's have all types inline-able, and then a globally-defined alias/reuse mechanism that supports all of them consistently. The one should not block the other, especially not given how PHP Internals works. --Larry Garfield

Seifeddine Gmati

60 days ago
> The main semantic question is whether callable/closure types should be defineable inline, or only as a reference (as in Rowan's C# example above.) In the past, there's been non-small pushback to defining them inline, as that can make for very hard to read function declarations and if the same signature is used in multiple places, you have to manually keep them in sync.
I don't think function types should receive special treatment allowing them to be defined outside as an alias. Complex type hints will start appearing more frequently as we continue to expand the type system. the solution is clear: type aliases. Until those land, i don't think any non-inline/reference solution for a specific type should happen tbh. Cheers, Seifeddine.

Matheus Martins

59 days ago
Totally with you on not special-casing closures. A general alias feature is the right long-term home. But I'd push back on waiting for it before settling the inline syntax, because the two aren't really alternatives. I'm no expert in the topic, but I guess an alias needs something to alias. use type callable(int): string as Foo; probably only works once callable(int): string is a valid type on its own or something like that. I mean supporting the inline syntax doesn't sound like conflicting / additional work that type alias could avoid. If that's correct, the inline grammar is the primitive; aliases are just a naming layer on top, and we would need inline either way. I just found that C# is a nice warning signal here: it started reference-only (you had to declare a named delegate per signature), found that painful enough that Func/Action were added precisely so you don't have to declare a delegate to spell a function type. See https://learn.microsoft.com/en-us/dotnet/api/system.func-2?view=net-10.0 Even the reference-only poster child ended up needing a declaration-free way to write these inline. Last but not least, the type-aliases RFC is still under discussion, with callable signatures sitting in future scope. Does it makes sense to wait for something that isn't a blocker nor an enabler?

Seifeddine Gmati

59 days ago
On Sat, 4 Jul 2026 at 12:01, Matheus Martins <mathrm@gmail.com> wrote:
> > Totally with you on not special-casing closures. A general alias feature is the right long-term home. But I'd push back on waiting for it before settling the inline syntax, because the two aren't really alternatives. > > I'm no expert in the topic, but I guess an alias needs something to alias. use type callable(int): string as Foo; probably only works once callable(int): string is a valid type on its own or something like that. I mean supporting the inline syntax doesn't sound like conflicting / additional work that type alias could avoid. > > If that's correct, the inline grammar is the primitive; aliases are just a naming layer on top, and we would need inline either way. > > I just found that C# is a nice warning signal here: it started reference-only (you had to declare a named delegate per signature), found that painful enough that Func/Action were added precisely so you don't have to declare a delegate to spell a function type. > > See https://learn.microsoft.com/en-us/dotnet/api/system.func-2?view=net-10.0 > > Even the reference-only poster child ended up needing a declaration-free way to write these inline. > > Last but not least, the type-aliases RFC is still under discussion, with callable signatures sitting in future scope. > > Does it makes sense to wait for something that isn't a blocker nor an enabler?
To clarify, I did not mean we should have no closure types until type aliases land. My point was specifically that we should not add dedicated "closure references" (like the C# delegates mentioned) before type aliases, as a general type alias feature would eventually make such specialized references redundant. I fully agree that we should have inline function types now, while leaving type aliases for later to solve the problems of repetition and signature complexity.

Larry Garfield

59 days ago
On Sat, Jul 4, 2026, at 10:11 AM, Seifeddine Gmati wrote:
> On Sat, 4 Jul 2026 at 12:01, Matheus Martins <mathrm@gmail.com> wrote: >> >> Totally with you on not special-casing closures. A general alias feature is the right long-term home. But I'd push back on waiting for it before settling the inline syntax, because the two aren't really alternatives. >> >> I'm no expert in the topic, but I guess an alias needs something to alias. use type callable(int): string as Foo; probably only works once callable(int): string is a valid type on its own or something like that. I mean supporting the inline syntax doesn't sound like conflicting / additional work that type alias could avoid. >> >> If that's correct, the inline grammar is the primitive; aliases are just a naming layer on top, and we would need inline either way. >> >> I just found that C# is a nice warning signal here: it started reference-only (you had to declare a named delegate per signature), found that painful enough that Func/Action were added precisely so you don't have to declare a delegate to spell a function type. >> >> See https://learn.microsoft.com/en-us/dotnet/api/system.func-2?view=net-10.0 >> >> Even the reference-only poster child ended up needing a declaration-free way to write these inline. >> >> Last but not least, the type-aliases RFC is still under discussion, with callable signatures sitting in future scope. >> >> Does it makes sense to wait for something that isn't a blocker nor an enabler? > > To clarify, I did not mean we should have no closure types until type > aliases land. My point was specifically that we should not add > dedicated "closure references" (like the C# delegates mentioned) > before type aliases, as a general type alias feature would eventually > make such specialized references redundant. > > I fully agree that we should have inline function types now, while > leaving type aliases for later to solve the problems of repetition and > signature complexity.
To also clarify, this is my position as well. Inline closure/callable signatures first, then figure out abstraction and reuse later. If someone gets fussy about the function signature being too long and complicated with an inline callable signature (as has happened in the past), the answer should be "that's nice, go work on aliases then and don't block this RFC". :-) --Larry Garfield

Larry Garfield

56 days ago
On Thu, Jul 2, 2026, at 2:14 PM, Larry Garfield wrote:
> On the question of callable-vs-closure, I agree that today, between FCC > and PFA a Closure is absolutely trivial to produce, so we don't need to > support the variety of legacy callable formats. The one caveat to that > is for compiled code; you cannot store a closure in a serialized form > or in generated code; functions and static methods are easy enough to > store that way (as a string and array, respectively), ugly as those > formats are. Methods, anon functions, etc. however are much harder, > and there's no globally standard way of cheating there. I suspect the > best we can do without scope creeping ourselves to death is just > support closures and leave it to implementers to turn other callable > formats into a closure, which isn't that hard these days.
I just realized one caveat to the above: Invokable objects. There's little point in doing $callableObj(...), other than the implementation of callable objects is kinda screwy right now and isn't part of any type. A callable type definition should support callable objects without forcing the user to squeeze them through closures. --Larry Garfield

Seifeddine Gmati

61 days ago
On Wed, 1 Jul 2026 at 15:43, Matheus Martins <mathrm@gmail.com> wrote:
> > Hello internals, > > I would like to revisit the idea of giving closures a typed call signature. > > e.g. Closure(int, string): array -- enforced at the point a value crosses a > type boundary (an argument, a return, a property), the same places any other > type is checked. > > Today a closure can only be typed as Closure or callable, neither of which > says anything about its parameters or return, even though that information is > right there. > > I know this is not new ground: Callable Prototypes was declined in 2016, and > Garfield and Grekas shared two further RFCs in 2023 -- Structural Typing for > Closures, and Allow Closures to Declare Interfaces they Implement -- both still > in draft. > > Before taking it further, I would like to know whether closure typing > is still considered worth pursuing -- or whether the topic is now regarded as > settled. > > References: > > - https://wiki.php.net/rfc/callable-types > - https://wiki.php.net/rfc/structural-typing-for-closures > - https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement > > Thanks.
Hi Matheus, I'm in favor of adding this. However, syntax wise, i would rather we re-use the `fn` keyword, e.g: - `fn(int): string` - `fn(string, int=): string` (`=` indicates the parameter is optional) - `fn(...string): string` (`...` indicates the parameter is variadic) - `fn(&string): void` (`&` indicates the parameter is by-reference) I also think restricting this to allow only `Closure` instance inputs is the right approach ( given that we have FCC ), as i think type checking array callables, and strings would be annoying and probably wasteful. Cheers, Seifeddine.

Matheus Martins

61 days ago
> I also think restricting this to allow only Closure instance inputs is the > right approach (given that we have FCC)
Agreed. That is the main thing. I am glad it makes sense for you too.
> syntax wise, i would rather we re-use the fn keyword, e.g: fn(int): string
Fair, and I would not block on the keyword -- it is the kind of thing an RFC can settle, with a secondary vote if needed. My one argument for Closure over fn: Closure is the actual type of the value. An arrow fn, a closure literal, and strlen(...) all report Closure from get_class(). Even if we support fn, it would be logical to support Closure as well. ```php echo get_class(Closure::fromCallable('strlen')); // Closure echo get_class(function () { return 1; }); // Closure echo get_class(fn () => 1); // Closure echo get_class(static fn () => 1); // Closure echo get_class(strlen(...)); // Closure ``` Therefore Closure matches what the engine already says everywhere and needs no new type keyword (Closure is an existing reserved class name). fn would introduce a type name nothing else reports -- you would write fn(...) but get_class() still says Closure -- and it is an expression-only keyword today. One concern on the markers, independent of the keyword: a name-less &type collides with intersection syntax. The lexer only reads & as by-reference when a variable follows it, so & before a bare type (&string) is the intersection operator and has no by-ref meaning there. I guess the exact spelling of by-ref/variadic/optional would be worth its own section in a RFC. Most important for now is making sure there's value on such feature. We can explore syntax and design once we agree it's worth the effort. Thanks for your feedback! Keep it coming :)

Osama Aldemeery

61 days ago
On Wed, Jul 1, 2026 at 5:43 PM Matheus Martins <mathrm@gmail.com> wrote:
> Hello internals, > > I would like to revisit the idea of giving closures a typed call signature. > > e.g. Closure(int, string): array -- enforced at the point a value crosses a > type boundary (an argument, a return, a property), the same places any > other > type is checked. > > Today a closure can only be typed as Closure or callable, neither of which > says anything about its parameters or return, even though that information > is > right there. > > I know this is not new ground: Callable Prototypes was declined in 2016, > and > Garfield and Grekas shared two further RFCs in 2023 -- Structural Typing > for > Closures, and Allow Closures to Declare Interfaces they Implement -- both > still > in draft. > > Before taking it further, I would like to know whether closure typing > is still considered worth pursuing -- or whether the topic is now regarded > as > settled. > > References: > > - https://wiki.php.net/rfc/callable-types > - https://wiki.php.net/rfc/structural-typing-for-closures > - > https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement > > Thanks. >
Hi Matheus, This is something I care about and took a real run at recently, but I came at it from a different angle, an `Invokable` marker interface PR <https://github.com/php/php-src/pull/21574> in which Gina pointed me at function types as the proper solution to what I was trying to address. I was convinced, withdrew the PR, and started exploring the same thing you are exploring now. So let me hand you what I ran into, in case it helps... Two things to put in your bag before you invest: 1. The syntax collides at the lexer. `Closure(int): array` can't be tokenized cleanly, because `(int)` is a cast token (same for `(string)`, `(array)`, and so on). It's been that way for years, and the one attempt to fix it (PR https://github.com/php/php-src/pull/1667) was rejected as a token-stream BC break. So the natural spelling is, unfortunately, the engine-hostile one. 2. There's a single `Closure` class (Ilija's point here: https://externals.io/message/120083#120099), so `Closure(int, string): array` isn't a subtype you can instanceof... it has to be checked another way at the boundary, which is where the usual per-boundary runtime-cost concern comes in. Hope you find that useful. Best, Osama

Matheus Martins

61 days ago
I'll check that. thanks!

Seifeddine Gmati

61 days ago
Hi Osama,
> The syntax collides at the lexer. `Closure(int): array` can't be tokenized cleanly, because `(int)` is a cast token (same for `(string)`, `(array)`, and so on). > It's been that way for years, and the one attempt to fix it (PR https://github.com/php/php-src/pull/1667) was rejected as a token-stream BC break. > So the natural spelling is, unfortunately, the engine-hostile one.
This is fixable, it's not a real limitation.
> There's a single `Closure` class (Ilija's point here: https://externals.io/message/120083#120099), so `Closure(int, string): array` isn't a subtype you can instanceof... > it has to be checked another way at the boundary, which is where the usual per-boundary runtime-cost concern comes in.
I agree on this, I think the `fn` keyword should be used here.