Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Larry Garfield]

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

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Larry Garfield]

On Sat, Jul 4, 2026, at 10:11 AM, Seifeddine Gmati wrote:
> On Sat, 4 Jul 2026 at 12:01, Matheus Martins  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

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Seifeddine Gmati]

On Sat, 4 Jul 2026 at 12:01, Matheus Martins  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.

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matheus Martins]

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?

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Seifeddine Gmati]

> 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.

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Larry Garfield]

On Wed, Jul 1, 2026, at 5:02 PM, Rowan Tommins [IMSoP] wrote:
> On 1 July 2026 20:02:27 BST, Seifeddine Gmati  
> wrote:
>>Making `Closure` generic (e.g., say `Closure` ) 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, Action, Func and so 
> on and on and on 
> 
>  
> 
>
> 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

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Rowan Tommins [IMSoP]]

On 1 July 2026 20:02:27 BST, Seifeddine Gmati  wrote:
>Making `Closure` generic (e.g., say `Closure` ) 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, Action, Func and so on and on and on 

 


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]

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Seifeddine Gmati]

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.

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matheus Martins]

... 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  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.)

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matheus Martins]

> 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.)

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matheus Martins]

I'll check that. thanks!

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matheus Martins]

> 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 :)

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Osama Aldemeery]

On Wed, Jul 1, 2026 at 5:43 PM 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.
>

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
 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

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Seifeddine Gmati]

On Wed, 1 Jul 2026 at 15:43, 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.

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.

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Seifeddine Gmati]

> 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` ) 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, string=): T` handles all of it
cleanly:

- The generic parameter ( `` )
- Te required and optional arguments ( `=` marker )
- The return type ( following `:` )

Cheers,
Seifeddine

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matthew Weier O'Phinney]

On Wed, Jul 1, 2026, 12:11 PM Matheus Martins  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
mweierophin...@gmail.com
https://mwop.net/
he/him

>

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Matheus Martins]

> 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?

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Rob Landers]

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

Re: [PHP-DEV] [Discussion] Revisiting typed closures

[Joe Watkins]

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,  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.
>