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 <[email protected]
> <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 [email protected].
For more options, visit https://groups.google.com/d/optout.
