Go Generics Changes: Constraints are ugly, move to x/exp first for experimental features

Hello everyone, I am fried fish.

Go generics come with various standard libraries, such as the common maps and 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
...

Or:

package slices

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

Pay attention to the standard library constraints inside, he is the protagonist of today's change. what's wrong with him?

background

The standard library constraints is a new thing, added by generics guy Ian Lance Taylor in his commit "constraints: new package to define standard type parameter constraints" on September 24, 2021.

As shown below:

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

reason

new proposal

In a heated discussion in the community, someone proposed a proposal "proposal: constraints: rename package to "of", hoping to rename the constraints package.

The new code is as follows:

func Abs[V of.Number](v V) V{...}

func Sum[K comparable, V of.Number](m map[K]V) V {...}

The author believes that using the "of" keyword is simpler and more fluid than "constraints".

This proposal has attracted a lot of discussion. I feel that the name of constraints is too long now. Once there are many function signatures, it will be cumbersome and uncomfortable to look at.

It is suggested to use reference alias to solve:

import of “constraints”

It is also said to use the name of any, is, or even std, or other import methods.

There are different opinions. Although the frequency of use of constraints has been greatly optimized, once it is used 2~3 times, there will be a problem that the function signature is too large.

It was ultimately rejected due to failure to discuss a clear consensus.

struggling conclusion

After this long generic push and naming controversy, Russ Cox found that there are still many problems with the constraint package, which are open to question.

They are:

• The name of the package is too ugly: Many people are very satisfied with the name of the package, that is, the constraints, and some are very dissatisfied, thinking that it is too long and too verbose.
• Don't know what to put: It's not clear which interfaces are important, should be there, and which shouldn't be, for what is put in the package.
• It doesn't seem to be necessary: at first it was thought that the constraints of the standard were the basis for using generics, but in practice it didn't prove to be the case, and it's even possible not to.

For the above reasons, the Go team decided to move the standard library constraints, like maps and slices, to x/exp as an experimental feature.

Revisit them in Go 1.19 or 1.20 to see if they really work, or how to use them correctly, and then decide.

Summarize

Go generics will be released in Go1.18 in this month (February) (in the Spring Festival, notify the community that it is March...), although from the surface, the core functions have been basically finalized, but The facilities are still quite messy.

It is recommended that everyone pay attention to the rhythm in formal production and use, so as not to step on the pit.

What do you think about the naming of constraints, welcome everyone to discuss :)

If you have any questions, welcome feedback and exchange in the comment area. The best relationship is .

The article is continuously updated, you can read it on WeChat search [Brain into the fried fish], this article GitHub github.com/eddycjy/blog has been included, learn Go language, you can see Go learning map and route

refer to

• proposal: constraints: move to x/exp for Go 1.18
• proposal: constraints: rename package to "of"