On Thu, 18 Oct 2018 at 06:44, Axel Wagner <axel.wagner...@googlemail.com> wrote:
> This is only tangentially related to your specific idea, but I've decided > that for generics discussions this is the hill I'm dying on: > > On Wed, Oct 17, 2018 at 6:44 PM roger peppe <rogpe...@gmail.com> wrote: > >> The method calls in question can be inlined because everything is known >> statically, so there's theoretically zero performance overhead. >> > > This is only true in the same sense that interfaces have zero performance > overhead today. Generics or not, it will remain true that either a) the > compiler uses static type information it can prove to generate static > calls, requiring inter-package analysis or b) the compiler doesn't do that > and has to generate dynamic calls. Whether you call that "how generics are > implemented" or "devirtualization" makes no practical difference. Except > that the latter also benefits "non-generic" (i.e. generic via the usage of > interfaces) code. > The difference is that for generics, you *always* know the exact set of possible types that a type parameter can be. The compiler can decide to generate a single generic function that can use several different types, but it can also choose to generate different code for each type, C++ style with zero overhead (modulo text segment size). For interfaces, there are *some* situations where the compiler can infer the type and choose to generate specialized code, but that's not possible in general. There is *some* difference, because generics allow to express ideas that > the language right now doesn't allow, like the difference between `Sum(type > T Adder) ([]T) T` and `Sum([]Adder) Adder` (where the latter requires to > construct a new slice containing interfaces), but they are not due to > static vs. dynamic dispatch or inlining. Though I guess you could even > argue that inlining + devirtualization could theoretically get rid of the > construction of the new slice. But I digress :) > > >> Generic functions that would previously have been able to use operators >> don't look as nice, of course, but maybe that's a price worth paying. >> >> Unfortunately this idea doesn't work very well because of a few reasons. >> Firstly. anything that is returned by a generic function still has the >> converted type. So the sum variable in main above has type Int, not int. >> Also, if one is converting to other types as a matter of course, one loses >> the type safety that comes with using different types. >> >> That said, maybe there's a glimmer of possibility here. You get a lot of >> potential for a very small language change, so I'm throwing out this idea >> in case someone has a good idea how to circumvent the above-mentioned >> problems. >> >> -- >> 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. >> > -- 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.
