On Thu, 18 Oct 2018 at 08:40, Axel Wagner <axel.wagner...@googlemail.com> wrote:
> 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. > For generics, that analysis is trivial - there is no need to do any control flow analysis to determine the set of possible generic type parameters to a type or function (with the exception of recursive generic functions, which can be disallowed). For interfaces, the job is much harder. Guru can do it, but only to a limited extent. And in general it's not possible a) because the number of possible types is not bounded (you can create new types with the reflect package, or by dynamically loading modules) and b) because you'd need to solve the halting problem. > 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. > It really can't. The analysis needed for parametric types need not look at anything other than type parameters. The analysis needed for interfaces needs to analyse the code itself. A few examples: https://play.golang.org/p/CEzBpsRIVGQ -- 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.
