If (somehow) Go get Ada style package based generics then a lot of the 
language doesn't have to change.

The consumer of the generic package will have to "instantiate" the package 
before using it. Therefore 
A codebase cannot be littered with parametric type variables.

So generic functions would become normal function upon instantiation of the 
generic package.

pseudo code ex: 

     package foo

     type T generic

     func Noop(t T)T{return T}


     package main

     import int_foo "foo" {T int}
     import string_foo "foo" {T string}

     var _ = int_foo.Noop(5) 
     var _ = string_foo.Noop("bar")

In fact, there might be even no need to change runtime behavior.

Le vendredi 9 mars 2018 06:54:48 UTC-9, Ian Lance Taylor a écrit :
> On Fri, Mar 9, 2018 at 6:39 AM, Maxim Ivanov <ivanov...@gmail.com 
> <javascript:>> wrote: 
> > 
> > Side question, would hyptohetical future generics substantially 
> > reduce number of API breaking changes? 
> I don't really see how.  In a language like Go, I think that any 
> plausible definition of generics implies adding type parameters to a 
> function.  Although those parameters may be specified in many 
> different ways with many different possible restrictions, at base they 
> amount to another kind of parameter, albeit one that is evaluated at 
> compile time rather than at run time.  Any change in those parameters, 
> however specified, is going to be an ABI breaking change.  (I would be 
> interested in hearing of any language that implements generics in a 
> way that maintains compile-time type checking but does not involve 
> some sort of type parameters.) 
> I'll note that while Axel's writeup is good, I personally would be 
> willing to treat adding a new field to a struct type or a new method 
> to a non-interface type as a non-breaking change.  It's true that it 
> can break people embedding types, but unless the docs specifically 
> encourage embedding types I think that is a sufficiently unusual case 
> that I wouldn't worry about it.  Which just goes to show that there is 
> indeed disagreement on these points.  For what it's worth, 
> https://golang.org/doc/go1compat does specifically permit adding 
> fields and methods, while acknowledging that that has the possibility 
> of breaking code. 
> Compatibility of course goes beyond function signatures, it goes to 
> behavior.  In the limit, it becomes impossible to make any user 
> visible change to a package, because of Hyrum's Law 
> (http://www.hyrumslaw.com/).  So while some changes clearly break the 
> ABI, and a few clearly do not, there is still a large grey area. 
> Ian 

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.

Reply via email to