-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
constraints: move to x/exp for Go 1.18 #50792
Comments
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
Change https://golang.org/cl/382535 mentions this issue: |
Move to exp from the pre-1.18 standard library. For golang/go#45458 For golang/go#50792 Change-Id: I70f054c9d68c20e98e750f6501f3eabd04a70f17 Reviewed-on: https://go-review.googlesource.com/c/exp/+/382535 Trust: Ian Lance Taylor <[email protected]> Run-TryBot: Ian Lance Taylor <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change https://golang.org/cl/382460 mentions this issue: |
The tests for |
Change https://golang.org/cl/382834 mentions this issue: |
Change https://golang.org/cl/383254 mentions this issue: |
Change https://golang.org/cl/383694 mentions this issue: |
…kage Following decision in golang/go#50792 Change-Id: I71d74b4b386aacef5319663c397479cac6feb32f Reviewed-on: https://go-review.googlesource.com/c/website/+/383694 Reviewed-by: DO NOT USE <[email protected]> Reviewed-by: Eli Bendersky <[email protected]>
This avoids importing the constraints package, which is no longer in the standard library. For golang/go#50792 Change-Id: I0e0f48d414e87418a1fe95e500bb7629127007cc Reviewed-on: https://go-review.googlesource.com/c/website/+/383254 Reviewed-by: Eli Bendersky <[email protected]> Reviewed-by: Eli Bendersky <[email protected]> Trust: DO NOT USE <[email protected]> Run-TryBot: DO NOT USE <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
The constraints builtin has been removed as per [this issue](golang/go#50792).
…kage Following decision in golang/go#50792 Change-Id: I71d74b4b386aacef5319663c397479cac6feb32f Reviewed-on: https://go-review.googlesource.com/c/website/+/383694 Reviewed-by: DO NOT USE <[email protected]> Reviewed-by: Eli Bendersky <[email protected]>
This avoids importing the constraints package, which is no longer in the standard library. For golang/go#50792 Change-Id: I0e0f48d414e87418a1fe95e500bb7629127007cc Reviewed-on: https://go-review.googlesource.com/c/website/+/383254 Reviewed-by: Eli Bendersky <[email protected]> Reviewed-by: Eli Bendersky <[email protected]> Trust: DO NOT USE <[email protected]> Run-TryBot: DO NOT USE <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
There are still questions about the the constraints package. To start with, although many people are happy with the name, many are not. On top of that, it is unclear exactly which interfaces are important and should be present and which should be not. More generally, all the considerations that led us to move slices and maps to x/exp apply to constraints as well.
We left constraints behind in the standard library because we believed it was fundamental to using generics, but in practice that hasn't proven to be the case. In particular, most code uses any or comparable. If those are the only common constraints, maybe we don't need the package. Or if constraints.Ordered is the only other commonly used constraint, maybe that should be a predeclared identifier next to any and comparable. The ability to abbreviate simple constraints let us remove constraints.Chan, constraints.Map, and constraints.Slice, which probably would have been commonly used, but they're gone.
Unlike other interfaces like, say, context.Context, there is no compatibility issue with having a constraint interface defined in multiple packages. The problems that happen with duplicate interfaces involve other types built using that type, such as
func(context.Context)
vsfunc(othercontext.Context)
. But that cannot happen with constraints, because they can only appear as type parameters, and they are irrelevant to type equality for a particular substitution. So having x/exp/constraints and later having constraints does not cause any kind of migration problem at all, unlike what happened with context.For all these reasons, it probably makes sense to move constraints to x/exp along with slices and maps for Go 1.18 and then revisit it in the Go 1.19 or maybe Go 1.20 cycle. (Realistically, we may not know much more for Go 1.19 than we do now.)
Discussed with @robpike, @griesemer, and @ianlancetaylor, who all agree.
The text was updated successfully, but these errors were encountered: