[PHP-DEV] [Discussion] Revisiting typed closures

Mailing Lists php.internals
1

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:

- PHP: rfc:callable-types
- PHP: rfc:structural-typing-for-closures
- PHP: rfc:allow-closures-to-declare-interfaces-they-implement

Thanks.

2

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:

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:

Thanks.

3

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:

Thanks.

I would rather wait for generics and possibly make Closure a generic type.

— Rob

4

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

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

5

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

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

6

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

7

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:

- PHP: rfc:callable-types
- PHP: rfc:structural-typing-for-closures
- PHP: 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.

8

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:

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

9

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.

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

10

I'll check that. thanks!

11

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

12

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

13

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 Fix T_*_CAST syntax issues that caused argument list edge cases by marcioAlmada · Pull Request #1667 · php/php-src · GitHub) 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: [Discussion] Callable types via Interfaces - Externals), 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.

14

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&gt; <https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.Private.CoreLib/src/System/Function.cs&gt;

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: Work with delegate types in C# - C# | Microsoft Learn

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]

15

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&gt;
<https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.Private.CoreLib/src/System/Function.cs&gt;

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:
Work with delegate types in C# - C# | Microsoft Learn

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

16

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.