how to update APIs for generics

[rsc]

@ianlancetaylor, @griesemer, and I are wondering about different possible plans for updating APIs that would have used generics but currently use interface{}, and we wanted to cast a wider net for ideas.

There exist types and functions that clearly would use generics if we wrote them today. For example:

• type sync.Pool would naturally be sync.Pool[T]
• type sync.Map would naturally be sync.Map[K, V]
• type atomic.Value would naturally be atomic.Value[T]
• type list.List would naturally be list.List[T]
• func math.Abs would naturally be math.Abs[T]
• func math.Min would naturally be math.Min[T]
• func math.Max would naturally be math.Max[T]

There are certainly more of these, both in Go repos and everyone else's code.
The question is what should be the established convention for updating them.

One suggestion is to adopt an "Of" suffix, as in PoolOf[T], MinOf[T], and so on.
For types, which require the parameter list, that kind of works.
For functions, which will often infer it, the result is strange:
there is no obvious difference between math.MinOf(1, 2) and math.Min(1, 2).
Any new, from-scratch, post-generics API would presumably not include the Of - Tree[K,V], not TreeOf[K,V] -
so the "Of" in these names would be a persistent awkward reminder of our pre-generics past.

Another possibility is to adopt some kind of notation for default type parameters.
For example, suppose you could write

type List[E any (= interface{})] struct { ... }

func Min[T comparable (= float64)](x, y T) T { ... }

The (= ...) sets the default for a type parameter.
The rule for types could be that the bracketed type parameter list may be omitted when all parameters have defaults,
so saying List would be equivalent to List[interface{}], which, if we are careful, would be identical to the current code,
making the introduction of a generic List as list.List not a backwards-incompatible change.

The rule for functions could be that when parameters have defaults,
those defaults are applied just before the application of default constant types in the type inference algorithm.
That way, Min(1, 2) stays a float64, while Min(i, j) for i, j of type int, infers int instead.

The downside of this is a little bit more complexity in the language spec,
while the upside is potentially smoother migration for users.
Like the "Of" suffix, an API with type defaults would be a persistent awkward reminder of our pre-generics past,
but it would remind mainly the author of the code rather than all the users.
And users would not need to remember which APIs need an "Of" suffix added.

Are there other options we haven't considered?
Are there arguments for or against these options that haven't been mentioned?

Thanks very much.

[randall77]

var i int
Min(i, 5)   // is Min[int]
Min(3, 5) // is Min[float64]

Would definitely be confusing. Especially if you converted from the former to the latter while debugging something.

[mibk]

And what about using !go1.18 and go1.18 build tags and actually change the definition, so modules using go 1.18 would need to be adjusted to the new syntax?

[bcmills]

@mibk, !go1.18 and go1.18 build tags would change the definition of the package, not its contents as viewed by the importer.

[rsc]

Min is probably just a bad example.
I agree with Keith that Min(i, j) being int but Min(1, 2) not being int is probably too surprising.
(And Min(1, 2) must stay a float64 for x := Min(1,2).)
So let's take Min off the table.

[nirui]

But what about

func min() int {
    return math.Min(3, 5)
}

or

func getPool() int {
    return pool.Get()
}

etc? Will they still be inferred as math.Min[float64]&sync.Pool[interface{}]{}, or they will be inferred to math.Min[int]&sync.Pool[int]{} to match the return type?

IMO a reasonable default is fine. math was accept&/returning float64 only, dudes just silently sit there casting int32 to float64 before feeding them to math.Abs (maybe crying internally at the same time). Now you can have math.Abs take and return float64, int32, int, uint, PackOf6 etc. So at very least the func Min[T comparable (= float64)](x, y T) T { ... } (or whatever syntax it will become) approach is not a lost.

[ianlancetaylor]

I want to note that this example:

var i int
Min(i, 5)   // is Min[int]
Min(3, 5) // is Min[float64]

is an issue in general, even without default type arguments. Suppose we have a hypothetical

alg.Min[T constraints.Ordered](a, b T) T

with no default type argument. Now we get

var f float64
Min(f, 5) // is Min[float64]
Min(3, 5) // is Min[int]

So I don't think introducing default type arguments makes this any worse.

[Merovius]

Personally, I don't like the asymmetry this would create between type-parameters and regular parameters. Default values for arguments is something that has often been asked about, but we never did it. To me, the case for default type arguments isn't really stronger than for default regular arguments though.

I also don't like introducing a new language feature just for a one-time migration. If the motivator for this feature is just the migration of pre-generics APIs to post-generics APIs, it will become de-facto obsolete in a year or so. I don't like that idea.

[rogpeppe]

Default type arguments, however, are motivated by a one-time migration of pre-generics APIs to post-generics APIs. At some point, there won't be any pre-generics APIs left (i.e. every new API created after go 1.18 is a post-generics API) and they become obsolete.

I'm not sure that's true. With a small tweak to the rules, default type arguments could be useful any time a type parameter is added to an existing API, which I suspect will be more than we currently think, particularly in larger programs.

The rule that I'd suggest tweaking would be this one:

The rule for types could be that the bracketed type parameter list may be omitted when all parameters have defaults

in favour of:

The rule for types is that they may be omitted if that parameter and all following parameters have defaults and all the following types are omitted as well.

That change could also be made at a later date without problem, I think.

I don't really buy the parallel with default function arguments - functions are first-class values in Go but generic types and functions are not, so the impact of adding default arguments to functions is considerably deeper and has more runtime implications (think of the issues that Python has with default arguments, for example) than adding them for type arguments.

[Merovius]

I'm not sure that's true. With a small tweak to the rules, default type arguments could be useful any time a type parameter is added to an existing API, which I suspect will be more than we currently think, particularly in larger programs.

I think wanting to add parameters to functions is even more common. And yet we never made that easier with default arguments. There are many changes to APIs which are fairly commonly useful. We don't support most of them.

If I want to, say, add a context.Context argument to a function, I have to come up with a new name for the migration. I don't see why adding type parameters should get any preferential treatment here.

[rogpeppe]

I think wanting to add parameters to functions is even more common. And yet we never made that easier with default arguments.

It might be more common, but adding function default parameters to the language is hard. I don't think anyone knows how to do it, and it would have big implications for existing code (I'm not sure it would be possible to add them without breaking compatibility). By contrast, adding default type arguments is easy.

[AndrewHarrisSPU]

I hope I'm not saying this in too abruptly - maybe I'm missing something - but would the rule rewrite effectively mean this:

The rule for types is that they may be omitted if that parameter and all following parameters have defaults and all the following types are omitted as well. Also, that the default won't be changed at a later point in time.

[apparentlymart]

I must admit that I'm not really sure how I feel about default types for type parameters or default values for function parameters, but one difference I can see between those two situations is that the patterns often employed to create later-extensible function signatures (e.g. a single argument of a struct type representing all the args, or the de-facto functional options pattern) are not applicable to type signatures.

In other words, if I have the foresight to predict that a particular function might need additional arguments later then there are API design patterns I can follow to make it possible to do so without a breaking change. It isn't clear yet what I would do if I anticipate additional type parameters being added in future. Perhaps optional type parameters with defaults is an answer to that (with that also being useful to retrofit type parameters where there were originally none), or perhaps there's some other answer (which may or may not address the problem of retroactively introducing type parameters to a pre-generics codebase).

[Merovius]

One more data-point: This strategy wouldn't help with sort.Slice, for example. At least as far as I can tell. Even though it looks like we might lean towards making that slices.Sort, I feel like this speaks against this as a general strategy. Many generic APIs can't just replace an interface{} with a type-parameter.

[rsc]

sort.Slice was always an odd-ball, because of the comparison function taking indexes and not values. It was never going to transition smoothly to generics.

[Merovius]

Yes. That's pretty much my argument :) I don't see a general strategy for smooth transition to generics working.

Personally, I'd rather figure out if we can do a v2 of stdlib packages or something like that and lean into cleaning up APIs for generics.

[rsc]

Most types are nothing like sort.Slice.

[carlmjohnson]

containers/heap has the same problem as sort.

[zephyrtronium]

Using new major versions for stdlib packages, e.g. sort/v2, seems like a clean solution to me. I've seen a few people mention this, generally with a disclaimer like "there seems to be opposition to the idea," but I haven't seen the counterarguments. As a bonus, the precedent could also facilitate redesigns independent of generics, like #26263 and #22697.

[smyrman]

I don't see any inherent difficulty with net/http/v2 and encoding/json/v2 and archive/zip/v2. I don't think it would make sense to have net/v2/http`. Maybe I'm missing something.

@ianlancetaylor, usually sub-packages import the parent package, so I wold think there are potentially acceptable reasons you might want the versioning to be after the first element. E.g. if introducing a breaking change to net.Listener in net/v2 (arbitrary example), then surely you would need a v2 pacakge of net/http as well, and then net/v2/http would be a sensible way of communicating that dependency.

Given package versioning in the standard library is done infrequently and with great care, then the added duplication and potential cleanup that would result of introducing versioning after the first path element, might be an acceptable trade-off.

[ianlancetaylor]

I don't think the interesting argument is whether the subpackage imports the parent package. I think the interesting argument is whether we would normally want to have a v2 version of all the subpackages at the same time. For example, it seems to me that writing a v2 of encoding/json or encoding/xml in no way implies that we need or want a v2 of encoding/binary or encoding/base64 or encoding/hex, or, for that matter, of encoding itself.

For the case of archive/zip, note that archive/zip does not import archive. In fact, there is no archive package.

[smyrman]

I think the interesting argument is whether we would normally want to have a v2 version of all the sub-packages at the same time.

I completely agree to that. I am not to worried either way, as I think the answer to this question would become more clear with proto-types. The more v2 proto-types (related to generics or not) the better. If the proto-type doesn't have to be in code, but could be in the form of a Gist or a blog article, then anyone can write one.

I won't be writing any proto-types in code, but I though I would do a few articles to visualize how a v2 of different packages might look like for generics in particular. I have started out with an article for sync/v2, showing a potential sync/v2/atomic as well. I will share it when it's in a more ready state. I also started looking at math/v2 which has a higher number of sub-packages. If anyone feeels inspired to write a piece on this, and beats me to it, then I don't mind.

[lpar]

None of this is meant to imply that versioning standard library packages is a good idea, or a bad idea. It does solve the problem at hand, but it's a little weird to have to remember to write math/v2.

Well, that’s a problem with Go’s package system in general, not specific to generics. I can’t be the only person who has gotten half way through using a third party library for something and only then discovered that I want the v2 version. (Or in some cases the v4 version, I’m looking at you UUID.)

A solution, of course, would be for the default to be the most recent if the version is not explicitly specified. Perhaps doing generics using regular package naming conventions could apply some pressure to solve that problem for packages in general?

There is no math2.h or java.lang.Math2.

On the other hand, Java’s library is now a decent date and time library plus an unholy mess of obsolete non-thread-safe functions that programmers have to remember to avoid. And there’s java.io2, they just decided to call it nio for New IO instead.

[smyrman]

I though I would do a few articles to visualize how a v2 of different packages might look like for generics in particular. I have started out with an article for sync/v2, showing a potential sync/v2/atomic as well. I will share it when it's in a more ready state.

My progress on this has been very slow as I have been busy with other stuff, but here is an early draft that might already be useful to read:

• intro: https://github.com/smyrman/blog/blob/master/2021-09-v2-for-generics/1-v2-for-generics.md
• sync/v2 + sync/v2/atomics: https://github.com/smyrman/blog/blob/master/2021-09-v2-for-generics/2-sync-v2.md

There is a very nice overview of suggestions to changes in #48287 (comment), but I have tried to go a little-bit more in depth. E.g. could we extend the assembly syntax to allow writing a generic version of the various functions in atomic? If so, we could reduce the number of functions from 29 to 5.

I haven't gotten down to write anything about the math package yet, not to mention math/big. I probably won't get the time to do so anytime soon, but I would actually accept PRs, and be sure to mention anyone contributing to the article if/when I decide to release them for a wider audience.

[ianlancetaylor]

Another approach is to observe that the language supports type aliases to support transitions. So let's use type aliases.

type Pool[T any] ...
type Pool = Pool[interface{}]

The rules here would be:

1. The type alias must be at the same scope as the type (which currently means only at package scope).
2. The type alias identifier would be the same as the alias target (otherwise it is an ordinary alias).
3. The type alias identifier must not have any type parameters.
4. The type alias target must specify arguments for all type parameters.

This alias rule does not work for functions. We can either say there is no transition for functions, or we can introduce another rule.

A function may be defined both with and without type parameters. A reference to the function (not a call) with no type arguments is permitted, and gets the version without type parameters. A call of the function with no type arguments gets the version with type parameters and does type inference as usual. If type inference fails, the call is instead made to the version without type parameters (and may fail if the arguments type are not assignable).

That gives us

func Min[T constraints.Ordered](a, b T) T { ... }
func Min(a, b float64) float64 { return Min[float64](a, b) }

[mvdan]

On the minus side, it's a bit odd to permit two different objects with the same name in a scope; in order to not break all kinds of invariants both in the implementation and in the go/types API, such a pair of type declarations would probably need to be considered a single object, but that is also strange: What is the object named "Pool"? Where is is declared?

Don't we have to worry about this problem anyway, due to #46477?

[gbarr]

An additional benefit for having 2 declarations as opposed to default types in the declaration is that they can have separate documentation. The new generic documentation can be kept clear without having to mention the compatibility defaults and the second declaration also allows the developer to mark it as deprecated in the documentation.

[akavel]

Seeing that this proposal (as many others too) is adding a language feature, I'd like to ask a question: would this language feature be defensible alone if the need for the transition from non-generics to generics didn't occur? I.e., if generics were there from the start, would this feature be deemed valuable enough to warrant its inclusion in the language? (I don't know the answer, I'd just like to make sure the Core Team themselves are consciously aware of the answer and take it into account when making a decision.)

[ianlancetaylor]

@akavel No, I don't think this language feature would be defensible if generics has been there from the start. It's a good question to ask. Still we have to do something (though we don't necessarily have to add a language feature, we can use different packages or different type/function names).

[GGCristo]

As an alternative to the "you can define a function more than once", i.e.

func Min[T constraints.Ordered](a, b T) T { ... }
func Min(a, b float64) float64 { return Min[float64](a, b) }

We could potentially simplify slightly more and say that you can define exactly one function with the same name without a body and the types therein will be used as a fallback if type unification fails. So, the above would be

func Min[T constraints.Ordered](a, b T) T { ... }
func Min(a, b float64) float64

I would like to add to @kylelemons's idea that the default function should be close to the fallback function, so code is more readable.
Also, this could be an alternative way of doing this in case using the "func" keyword feels like a hack

[T = float64]
func Min[T constraints.Ordered](a, b T) T { ... }

[ianlancetaylor]

It's clearly essential to always have a crazy idea that everybody can reject, so here is one. default is already a keyword. So let's permit, only at package scope,

default Pool Pool[interface{}]
default Min Min[float64]

[griesemer]

This is essentially the same as the alias idea above (at least for types), except that a keyword is used.

[changkun]

Not necessarily need the default keyword, this might be more consistent with the subject:

type Pool[T any] ...
type Pool = Pool[interface{}] // type alias

func Min[T constraints.Ordered](a, b T) T { ... }
func Min = Min[float64]       // func alias

(° ο°)...

[jpap]

I like the idea of keeping the declaration as one: with a separate alias/default declaration, one of the two parts might end up far from the other, reducing source code readability.

What about using the default keyword with the original proposal:

type List[E any default interface{}] struct { ... }

func Min[T comparable default float64](x, y T) T { ... }

func Print2[T1 any default string, T2 any default interface{}](s1 []T1, v2 []T2) { ... }

[bcmills]

One suggestion is to adopt an "Of" suffix, as in PoolOf[T], MinOf[T], and so on.
For types, which require the parameter list, that kind of works.
For functions, which will often infer it, the result is strange:
there is no obvious difference between math.MinOf(1, 2) and math.Min(1, 2).
Any new, from-scratch, post-generics API would presumably not include the Of - Tree[K,V], not TreeOf[K,V] -
so the "Of" in these names would be a persistent awkward reminder of our pre-generics past.

I'm going to go out on a limb and suggest that we use the Of suffix for generic container types, regardless of whether they are new. Then the Of in the names is no longer a persistent awkward reminder, but a consistent pattern.

Constructor functions for generic containers get the Of suffix because the type has it, and because they can't generally be inferred locally anyway: list.NewListOf[T]().

math gets a mulligan for using the good names for the 64-bit-only variants: v2 it. import "math/v2" and the only call sites that change are the ones that can't infer arguments (e.g. Nan()) or pass only untyped constants. Then maybe we can revisit the awkward inclusions for that package at the same time. (Do people really use math.Yn on a regular basis‽)

I think atomic.Value needs more thought anyway (#47657 (comment)). So maybe v2 that package too, or use names that aren't just ValueOf..?

If we do the above, what are the remaining problematic names?

[rsc]

Didn't that ship sail with map?

[bcmills]

Maybe, but as a built-in it's already funny-looking. (And its second type parameter spills outside the brackets! 😅)

[kylelemons]

The idea clearly exists already, as it was mentioned in this thread but I think it's worth its own suggestion as I think it aligns pretty nicely with what we're asking package maintainers to do in general:

Don't introduce generics in most of these libraries. /v2 them:

• "sync" -> "sync/v2" gets generic Value, Pool, Map
• "math" -> "math/v2" gets generic Abs, Min, etc
• "list", "heap", "ring", etc get "list/v2", etc for their generic versions.

The normal packages should be implementable in terms of the generic version, so if it doesn't compromise performance we could do the go fix trick to rewrite them all to /v2.

[twmb]

If choosing a v2 approach, I think it'd be worth it for gopls / goimports / etc. to adopt a convention of importing v2 by default if go.mod uses go.1.18+ (which it should, if a library / binary is using generics).

[lu4p]

Alternatively /v2/math, /v2/sync, etc, to fit the usual module-version style. That means we'd have a single v2 directory with all the new API in. As you say, all the current packages should be implementable in terms of the new API.

I think this is not the right approach because stdlib packages might want to version independently from another in the future. (e.g. math/v3 while sync is still at v2)

[Merovius]

@lu4p That's not something precluded by putting the version in front. Effectively, the v3/math might exists, while v2/sync doesn't, until we decide to revamp it again. The std as a module is already special (in that you don't need to put the module path into the import), there's no reason to force it to upgrade all packages at once.

[nickkeets]

What if we take this one step further? Go 1.18 becomes Go 2 and importing v2/math etc happens by default, with import math. But, we also keep the old versions too as v1/math etc. We do break compatibility this way, but in a way that can be ported automatically with go fix.

[ncruces]

@nickkeets, if the Go community really stands by SIV, there's no reason to exclude the standard library from the associated ugliness.

[rogpeppe]

I support this suggestion, particularly as I see it as having the potential to be generally useful into the future given a minor tweak to the rules.

I'd question the need for the parentheses. I understand that they're there to suggest the "maybe" aspect of the default but I don't think they pull their weight, and there's considerable precedent from other languages (e.g. Rust's default type parameters, Python's default function parameters) that they could be omitted without much confusion.

That is, I think it would be fine if the examples were written thus:

type List[E any = interface{}] struct { ... }

func Min[T comparable = float64](x, y T) T { ... }

[AlaxLee]

Drop the parentheses is good idea. "=" usually used for "equal" or "assignment", if we can use another word instead of "="?
For example:
type List[E any default interface{}] struct { ... }

[AndrewHarrisSPU]

I agree the sense in which E would be assigned interface{} as a default value by = feels a bit out of place here. default seems a little more obvious. Really, I think the type assertion syntax is the strongest analogy: E.(interface{}) in the production of type List[E.(interface{}) any] struct { ... }. (Maybe it's clearer to say it's a type judgement, as 'assertion' can imply something that can fail?)

The spec states the following for the type assertion from an interface x.(T):

... even though the dynamic type of x is known only at run time, the type of x.(T) is known to be T in a correct program.

Here we would be analogously stating for a type judgement E.(interface{}):

... even though the concrete type of E is only known at instantiation time, the type of E.(interface{}) is known to be interface{} in a correct program.

This judgement holds even if no other instantiation of E can be reached ... so, there is a subtle difference between E any and E.(any) any.

For Min[T.(float64) comparable](x, y T) T { ... }, when something like Min(1, 2) returns float64, maybe it's sensible to say it's a judgement?

[AlaxLee]

IMHO, There may be a confusing place here.
When using x.(T), it often means:

if x's type is T, right; if not T, wrong.

When using E.(interface{}) in type List[E.(interface{}) any] struct { ... }, it means:

if E's type is interface{}, right; if not interface{}, right too.

[DeedleFake]

Is this something that could be handled by the go directive in go.mod? Something like go 1.18 and up changes them to generic versions, with a go fix directive to add an explicit sync.Map[interface{}, interface{}] and the like? This would obviously only work for the standard library, but external modules can use a major version update to introduce generics instead.

It seems like overkill for something like this, and if a clean alternative can be found than that's probably better, but I hadn't seen it discussed anywhere and introducing incompatibilities was one of the primary motivations for adding the directive, if I remember correctly.

[bcmills]

That option came up a bit in #48287 (comment). (I think the tricky part is in defining the syntax for the declaration site.)

[suared]

Why would that be required? Wouldnt it be a 1 time fix?

[akavel]

A proposal/idea related to various more or less vague "go fix" approaches already mentioned around here and there, but specific enough and subtly different enough to warrant separate mention, given this is clearly a brainstorming discussion:

• Treat go version directive in go.mod as transition point, such that:
  • for code having version < go1.18, new packages are available via import "go2/math" etc., old packages via regular import "math"
  • for code having version >= go1.18, new packages are now available via import "math" etc., old packages via import "go1compat/math"
  • a go fix upgrade (or similar) rewrites the imports & bumps the go version directive in go.mod

(obviously, the "go2/" and "go1compat/" prefixes being subject to bikeshedding, and go1.18 subject to change to newer)

edit: Notably, AFAIU this is also basically how Rust editions are working, so Rust community leaders could be consulted about any nonobvious pros or cons of this approach. FWIW, from a distance it seems to be working for them well enough that they repeated this "phase transition" a few times already. Also, if adopted, this could possibly also help with other bigger "Go2" changes if needed at some point.

edit 2: This also seems to me fairly similar to the /v2, /v3, etc. versioning in 3rd-party packages, as introduced with the modules system. The difference being, Go stdlib under this proposal would come with a "deflation" mechanism via go fix, basically purely for ergonomy/ease-of-writing's sake. Though the disadvantage of this "deflation system" would be that when reading Go code, one could then not be immediately sure which version of the stdlib the code is using - only being able to discern this after looking into go.mod.

[ianlancetaylor]

I think this could work but I think it would be difficult for people to understand. It's always problematic when the exact same code means different things based on some other file. It makes it much harder to understand the code when reading it. In this case the problem is somewhat mitigated because it is a one time transition cost. But still.

[oxplot]

We could teach go.mod replace to work with stdlib packages.

As an example:

module xyz

go 1.18

replace sort => typed/sort

require (
  ...
)

Benefits:

• Backward compatibility: all parameterized types are under typed/ (or something similar)
• Explicit: no magical compiler behavior choosing one version over another based on some heuristic.
• New code can trivially use the go.mod replace (and go mod init can add the replace directive automatically for Go versions that support generics).
• Existing code can be migrated by explicitly naming the import path import sort "typed/sort".
• Go 2 will rename all typed/* to * and provide code upgrade tool.

[Merovius]

This seems unhelpful to me. Library code is going to want to use the new versions of packages and can't rely on replace. So they will have to type out the entire path. At that point, it seems simpler and less confusing to just have everybody type out the full import path.

[renthraysk]

Is the plan to keep the generics behaving the same as the original?

As implemented as a generic bits.RotateLeft() the inliner is assigning a much higher cost (almost x2) to the function. Whilst doesn't prevent it from inlining, it prevents the caller, QVarint(), from inlining (non-generic cost is < 50, generic cost is > 120), even though the assembly generated from the generic code is practically identical to the assembly generated from the non-generic code.

type Unsigned interface {
	~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uint
}

func BitWidth[T Unsigned]() uint {
	return uint(8 + (T(8<<8) >> 8) + (T(16<<16) >> 16) + (T(32<<32) >> 32))
}

func RotateLeft[T Unsigned](x T, k int) T {
	n := BitWidth[T]()
	s := uint(k) & (n - 1)
	return x<<s | x>>(n-s)
}

func QVarint[T Unsigned](x T) (uint64, int) {
    y := uint64(RotateLeft(x, 2))
    n := uint(8) << (y & 0b11)
    if w := BitWidth[T](); w == 64 || n <= w {
        s := w + 2 - n
        return y >> (s % 64), int(n / 8)
    }
    // truncated 
    return 0, -1
}

func main() {
	x := uint64(1 << 56)
	y, n := QVarint(x)
	_, _ = y, n
}

[rsc]

It is definitely the case that if we write generic APIs that we expect to be inlined, we will need to pay attention to the cost assumed by the inliner in higher-level frames. Thanks for raising this issue.

[bmhatfield]

A possible awful idea for rejection: implementation-specific suffixes akin to _unix, _windows, etc, but for generics/not: _generic, _typed. This would allow us to compile a typed version in contexts where generics are not available, and a generic version where they are. Also possible/less collide-y would be version build suffixes instead (_1.17, _1.18`).

This builds on the observation:

For functions, which will often infer [the type], the result is strange:
there is no obvious difference between math.MinOf(1, 2) and math.Min(1, 2).

[clarkmcc]

If these suffixes behave anything like existing suffixes, then you could only flip generics on or off for the entire project at compile time. In my opinion, a solution that allows incremental migration of existing projects rather than an all or nothing approach is pretty valuable.

[jxsl13]

I wonder how much compilation time it would take if the function signatures would also be distinguished by their parameter lists. Preferring a generic implementation over the interface one.
Just a thought..

[matt0xFF]

For generic math, type/function aliases would be better than default parameters.

Edit: As long as you can add parameters in an alias to a different name (type mgl32.Vector3 = mgl.Vector3[float32]), I think all of these cases would work with a combination that and default parameters - if default parameters are included, they don't require aliases to the same name.

For example the mathgl packages include 3D math types used by OpenGL bindings / games etc. There are 32 and 64 bit versions of each type, mgl32.Vec3/mgl64.Vec3, mgl32.Mat2x3/mgl64.Mat2x3, etc. Type aliases would allow each package to point to (and be compatible with) common generic versions of each type, but a default parameter wouldn't work since each package needs a different one (same thing for the functions, although wrapper functions would also be fine if they can be optimized away).

If Go ever permits array size type parameters (#44253), the type alias mechanism could also be used to aid migration in the same way (Vector3 could become an alias for Vector[3]).

Another example of math code (mathf.go) in the wild uses the f suffix (sinf, cosf) for 32 bit versions of math functions - type aliases would work there while default parameters wouldn't.

For those suggesting library authors break API compatibility, then all packages using those libraries re-writing to use the new API - I think we need to be realistic that this will not rapidly or completely happen. Many tasks currently work fine without generics (for example, 64-bit math code), so many applications and libraries would need to change a large number of files for zero or marginal benefits (changes that may include forking dependencies that are no longer actively maintained).

Even new code might continue to use "math" instead of "math/v2", if you are using 64-bit math, the former is shorter, and what's the difference?

I think the likely outcome is that users would need to be familiar with multiple ways to do the same thing (across many libraries) for the foreseeable future. Creating such a situation in the name of simplicity seems like a false economy.