proposal: spec: sum types based on general interfaces
This is a speculative issue based on the way that type parameter constraints are implemented. This is a discussion of a possible future language change, not one that will be adopted in the near future. This is a version of #41716 updated for the final implementation of generics in Go. We currently permit type parameter constraints to embed a union of types (see https://go.dev/ref/spec#Interface_types). We propose that we permit an ordinary interface type to embed a union of terms, where each term is itself a type. (This proposal does not permit the underlying type syntax `~T` to be used in an ordinary interface type, though of course that syntax is still valid for a type parameter constraint.) That's really the entire proposal. Embedding a union in an interface affects the interface's type set. As always, a variable of interface type may store a value of any type that is in its type set, or, equivalently, a value of any type in its type set implements the interface type. Inversely, a variable of interface type may not store a value of any type that is not in its type set. Embedding a union means that the interface is something akin to a sum type that permits values of any type listed in the union. For example: ```Go type MyInt int type MyOtherInt int type MyFloat float64 type I1 interface { MyInt | MyFloat } type I2 interface { int | float64 } ``` The types `MyInt` and `MyFloat` implement `I1`. The type `MyOtherInt` does not implement `I1`. None of `MyIn
Posted by ianlancetaylor on Jan 5, 2023, 11:56 PM
Tags
Related issues
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
github (EdTech)
Message limit 10000 team edition
[NEW] Data Tiering - Valkey as general data store not just in-memory data store
Info: No releases on google play for now
proposal: spec: sum types based on general interfaces
Users can't use IdPs outside of the ones enumerated by RPs
proposal: spec: sum types based on general interfaces
This is a speculative issue based on the way that type parameter constraints are implemented. This is a discussion of a possible future language change, not one that will be adopted in the near future. This is a version of #41716 updated for the final implementation of generics in Go. We currently permit type parameter constraints to embed a union of types (see https://go.dev/ref/spec#Interface_types). We propose that we permit an ordinary interface type to embed a union of terms, where each term is itself a type. (This proposal does not permit the underlying type syntax `~T` to be used in an ordinary interface type, though of course that syntax is still valid for a type parameter constraint.) That's really the entire proposal. Embedding a union in an interface affects the interface's type set. As always, a variable of interface type may store a value of any type that is in its type set, or, equivalently, a value of any type in its type set implements the interface type. Inversely, a variable of interface type may not store a value of any type that is not in its type set. Embedding a union means that the interface is something akin to a sum type that permits values of any type listed in the union. For example: ```Go type MyInt int type MyOtherInt int type MyFloat float64 type I1 interface { MyInt | MyFloat } type I2 interface { int | float64 } ``` The types `MyInt` and `MyFloat` implement `I1`. The type `MyOtherInt` does not implement `I1`. None of `MyIn
Comments (0)
No comments yet. Start the discussion.