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. 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.
