[vptr]

> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts.

I have a feeling this won't happen.

[oppositelock]

You're right. I maintain a very large code base in a private repo and a successful open source project. Generics will allow me to clean up a lot of code duplication internally, but given that Go modules are distributed as source code, this would force everyone to use Go 1.18.

My plan is to not use generics for quite a while, as it's pointless to have two separate implementations, one for 1.18 and one for < 1.18, which is difficult, because I really like the feature.

[ithkuil]

Upgrading to the latest release of the Go toolchains is generally a painless experience; the Go team has a good track record of enforcing backward compatibility. Hopefully this means that you can assume other users will be able to use code targeting new features of go 1.18 in pretty much the same time window it takes for other releases to supplant old ones, and make this feature not unlike previous (minor) language features that nevertheless would break users who cling to too old toolchains.

I hope that the publicity caused by generics doesn't taint this release causing people to unnecessary procrastinate a toolchains update they would have otherwise done if it wasn't for generics.

[oppositelock]

Sometimes, people can't be on the latest version of software due to various compliance and regulatory issues, and updating anything to a new version requires some kind of re-certification or new auditing. So, when supporting such users, you need to work carefully on balancing their inability to update, versus yours to move ahead.

Hacking on some projects or experiments is one thing, but say you're providing code for the automotive industry or the payment card industry; you're in for a world of regulatory hurt.

[gonzo41]

Well for the users, they should be upgrading anyway. I can't see a situation where someone would mirror your library in and not also have brought, or be bringing in a non breaking language change in the new golang. The only change management advice I could give, that you'll probably know, would be to roll a month slower than golang.