On Sat, Jul 4, 2026, at 10:11 AM, Seifeddine Gmati wrote: > 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.
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
