Re: [Discussion] Revisiting typed closures

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.