On Sat, 4 Jul 2026 at 12:01, Matheus Martins <[email protected]> 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.
