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?
