Hello, I’m fried fish.

The Go generics come with various standard libraries, such as the familiar Maps, Slices generic libraries.

In the early days they looked like this:

package maps

func Keys[M constraints.Map[K.V].K comparable.V any](m M) []K

func Values[M constraints.Map[K.V].K comparable.V any](m M) []V.Copy the code

Or:

package slices

func Compare[E constraints.Ordered](s1, s2 []E) int.Copy the code

Look at the standard library constraints, which is the subject of today’s changes. What happened to him?

background

The standard library constraints is new, and was submitted by Ian Lance Taylor on September 24, 2021 by Constraints: New package to define Standard Type parameter constraints.

The diagram below:

The main effect is to add a constraints package that defines some of the standard useful constraints, so we will see the use of these standard constraints in the common library.

The reason

The new proposals

During a heated discussion in the community, there was a proposal called proposal: Constraints: Rename Package to “of” to rename the Constraints package.

The new code looks like this:

func Abs[V of.Number](v V) V{... }func Sum[K comparable.V of.Number](m map[K]V) V{... }Copy the code

The author finds it easier and smoother to use the keyword “of” than “constraints”.

The proposal led to a lot of discussion that the name constraints was now too long, and that it would be cumbersome and uncomfortable to look at once the functions had more signatures.

Reference aliases are recommended:

importOf "constraints"Copy the code

There are also any, is names, even STD, or other import methods.

Although the frequency of using Constraints has been greatly optimized in the future, once it is used two or three times, the function signature becomes too large.

It was rejected because it failed to reach a clear consensus.

Conclusion of struggle

After this long generics push and naming controversy, Russ Cox found that there are still a lot of issues with the constraint package that need to be discussed.

Respectively is:

  • Ugly package name: Many people are happy with the name of the package, which is constraints, but also unhappy with it, finding it too long and verbose.
  • Don’t know what to put in: It’s not clear which interfaces are important and should exist and which should not for things that are put in packages.
  • It doesn’t seem necessary: Standards constraints are initially thought to be fundamental to the use of generics, but this has not proved to be the case in practice, and can even be eliminated.

For these reasons, the Go team decided to move the standard library constraints into X/EXP as an experimental feature, along with maps and Slices.

Review them again in Go 1.19 or 1.20 to see if they are really useful, or what is the right thing to do, and make a decision.

conclusion

The Go generic will be released in Go1.18 this month (February). On the face of it, the core functions have been basically finalized, but the supporting facilities are still a mess.

It is suggested that we should pay attention to the rhythm in formal production and use so as not to step on pits.

What do you think of the name constraints? Welcome to discuss 🙂

If you have any questions, welcome feedback and communication in the comments section. The best relationship is mutual achievement. Your praise is the biggest motivation for the creation of fried fish, thank you for your support.

This article is constantly updated. You can read it on wechat by searching “Brain into fried fish”. GitHub github.com/eddycjy/blo… Already included, learning Go language can see Go learning map and route, welcome Star urged more.

reference

  • Proposal: Constraints: move to x/exp for Go 1.18
  • proposal: constraints: rename package to “of”