Re: [Discussion] Revisiting typed closures

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