On Thu, Oct 18, 2018 at 9:16 AM roger peppe <rogpe...@gmail.com> wrote:
> The difference is that for generics, you *always* know the exact set of > possible types that a type parameter can be. > If and only if you choose to do that analysis. AFAIK it is not currently planned to do that <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#efficiency>. And if you are willing to do it, you can also apply this analysis to interfaces. 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. > True. This is a limitation of generics though - they can not be used in these general circumstances ;) Specifically, that's why type parameters on methods <https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md#discussion-and-open-questions> or passing of uninstantiated generic types/functions are disallowed in the design <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#instantiating-a-function>, AIUI. Those are basically the situations where true dynamic dispatch is required by theory. But in the case where your first paragraph applies - i.e. you can statically know the full set of types a generic function or type is instantiated with - the exact same analysis can also provide exactly the same results for interface-based polymorphism. > 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.
