Last addition: On Sun, Oct 21, 2018 at 2:03 PM roger peppe <rogpe...@gmail.com> wrote:
> Ah, I *think* I see where you might be coming from now. You're thinking > that the compiler could do some kind of Go-to-Go transformation for generic > functions so that they looked exactly as if they'd been written using > interfaces, and then later transform that back into devirtualized calls. > Even if it were possible in general (I'm fairly sure it's not), I don't see > why anyone would want to take such an indirect approach when it's quite > possible for the compiler to compile to an intermediate format that > preserves all the information needed and decide how to generate the code > based on that. > The claim you made was, that generics improve performance (due to static dispatch and inlining etc). I contradict that claim. I believe static dispatch and inlining can be achieved without talking about type-parameters or generics at all. And to answer the question of "why would you do that" - because if you treat it as a generic (lol) devirtualization pass, code that *doesn't* use generics (but does use interfaces) also benefits from that automatically. For example we could actually get a powerful and properly performing version of image/draw without having to re-write it into a parametric API - the performance of existing interface-based APIs would be equivalent to parametric ones. It's also easier to reason about, because you are separating the type-checking phase from the optimization phase. Your heuristics doesn't need to know about the generic type info at all and you can tweak both individually. Essentially, the advantages of splitting it into modular pieces is the same reason, why functional languages desugar all language constructs into pure functions - if `->` is the only type constructor you need to worry about, it becomes much easier to talk about how different features interact, optimizations and whether a change to the type-system is sound. Also, optimizations for that basic type-constructor compound to all constructs. In essence, a lot of the problems discovered in the alias-discussion and also in the generics discussion now come down to a question of how these things interact with all the existing features and whether we fully understood the whole space of programs the language allows. Treating generics as essentially syntactic sugar for interfaces/reflect/… creates orthogonality - at least in every compilation stage *after* type-checking. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
