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.
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
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/allow-closures-to-declare-interfaces-they-implement
Thanks.
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
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 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
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.)
... 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!
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):boolI 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.)
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
Making
Closuregeneric (e.g., sayClosure<Input, Output>) would
requireInputto 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]
Making
Closuregeneric (e.g., sayClosure<Input, Output>) would
requireInputto 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.csUgly, 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
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.
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?
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.
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
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
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): stringfn(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.
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 :)
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/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:
- The syntax collides at the lexer.
Closure(int): arraycan'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. - There's a single
Closureclass (Ilija's point here:
https://externals.io/message/120083#120099), soClosure(int, string): arrayisn'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
I'll check that. thanks!
Hi Osama,
The syntax collides at the lexer.
Closure(int): arraycan'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
Closureclass (Ilija's point here: https://externals.io/message/120083#120099), soClosure(int, string): arrayisn'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.