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