Love the implications of this as a compile time alternative for reflection, really hope I never run into it personally though.

So realistically, the interceptable method will always know which generator(s) will target it ahead of time, right? There’s no reason to put an [Interceptable] attribute on the method otherwise, after all. (In the video it seems like that’s not required in the current prototype, but I saw no mention of removing this in the issue discussion. Perhaps that check was just not implemented yet?)

To me this seems like a very weird version of Lisp macros, with their implementation hidden away in those generator(s) and essentially comefroms hidden away in the generated code. Though I suppose this is technically more powerful than macros because the generators are presumably allowed to look not just at the call itself but at the code around a call.

I suppose it’s mostly the comefrom-iness I dislike about it. Now the code could do something entirely different, without any indication at the call site (unless you have your IDE highlight this for you or something). I feel like this language feature would make it harder to keep a mental model of what’s going on in the code in my head, especially if it winds up getting used for things that actually change the behavior of the code (e.g. AOP) instead of just doing essentially “the same thing, but faster and without reflection”.

I like that they’re working on stuff like this, but perhaps just not exactly like this.