Yeah, my personal preference would be to desugar all these literal function reference forms into ClosureExprs in the type-checked AST so that SILGen doesn’t need to special case them all, leading to more stable and predictable codegen behavior when refactoring between different equivalent syntaxes.
1 Like
That might be true, but removing something completely always allows us to introduce a new behavior in the future, which wouldn’t be possible if we kept always everything around. I’m not saying we should remove the old syntax and behavior immediately, but shouldn’t we at least aim for some deprecations that will be obliterated after a few more years completely?
1 Like
When you say “all these literal function reference forms”, what are you referring to? What different forms of literal function references are there?
The various “bound” (baseValue.method) and “unbound” (BaseType.method) forms are actually quite complex to implement. Class methods, methods on protocol-constrained generic parameters, and methods on protocol values that return Self all require special handling. Unbound references on protocol types don’t work yet either. It would be nice to remove all this special handling from SILGen and redo it in terms of AST lowering instead.
4 Likes
This would be great but I think we’re missing a couple of things before we can do that in full generality. For example, we don’t have a way to express vararg forwarding in the AST right now, so you wouldn’t be able to tear off methods taking variadic arguments until it was implemented.