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