Re: [Discussion] Revisiting typed closures

On Sat, Jul 4, 2026, at 10:11 AM, Seifeddine Gmati wrote: > On Sat, 4 Jul 2026 at 12:01, Matheus Martins <mathrm@gmail.com> wrote: >> >> 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