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
On Fri, Mar 9, 2018 at 6:39 AM, Maxim Ivanov 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
>
> Yes, definitely. The only way that *wouldn't* break a reverse dependencies
> code is if they'd only use the function with number-literals. Which is
> sufficiently unusual to be put very firmly on the "breaking change" side of
> things.
>
And even then it technically breaks, because range
Yes, definitely. The only way that *wouldn't* break a reverse dependencies
code is if they'd only use the function with number-literals. Which is
sufficiently unusual to be put very firmly on the "breaking change" side of
things.
FWIW, I've written
In the light of recent vgo discussion, I was thinking about what would be
major change or and what wouldn't.
Wanted to ask Goers, in the new better post vgo world, if you changed
exported function argument from *int* to *float*, would you release your
package as v2?
--
You received this