proposal: spec: permit referring to a field shared by all elements of a type set #48522
Comments
|
@gopherbot, please add label generics |
dr2chase
added
the
NeedsInvestigation
|
Reading "Composite types in constraints" in https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md I get the impression that this ought to work; the example there says "this doesn't work because the field types for X don't all match" which implies that if the field types did match, as they do here, then it would work. |
|
We don't currently support field accesses of this kind even though the proposal says that this should/could work. We may not support this for Go1.18 as it doesn't seem like an essential feature. There's a trivial work-around that uses a method: package main
import "fmt"
type Point struct {
X, Y int
}
func (p Point) GetX() int { return p.X }
type Rect struct {
X, Y, W, H int
}
func (r Rect) GetX() int { return r.X }
type Elli struct {
X, Y, W, H int
}
func (e Elli) GetX() int { return e.X }
func GetX[P interface { Point | Rect | Elli; GetX() int }] (p P) int {
return p.GetX()
}
func main() {
p := Point { 1, 2}
r := Rect {2, 3, 7, 8}
e := Elli {4, 5, 9, 10}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
}Of course, then you don't need generic code in the first place because you could just use dynamic method dispatch. And maybe you should. |
|
The reason I tried this out is for #48499, wherr the OP directly wants to get fields or pointers to fields from a set of similar structs. In that use case, the overhead of an accessor function and dynamic method dispatch would be not acceptable. So while it may not be essential, #48499, which is for use with Go language databases, goes to show that it is not academic, but actually would be very useful for existing code, in stead of the feature proposed in that issue. Furthermore it is more consistent and easier to learn to also allow it. If there is not enough time left to implement this for 1.18, then please consider this for 1.19. |
griesemer
added
NeedsDecision
|
Open question here. I feel this is a bit restrictive because we have to explicitly say which struct statisfy the constraint. Like for the interface we may want something that will allow us to tell what is the constraint not who can pass. For example : package main
import "fmt"
type Point struct {
X, Y int
}
type Rect struct {
X, Y, W, H int
}
type Elli struct {
X, Y, W, H int
}
func GetX[P struct { X int }] (p P) int {
// here p is known to have only the field X anything more
return p.X
}
func main() {
p := Point { 1, 2}
r := Rect {2, 3, 7, 8}
e := Elli {4, 5, 9, 10}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
}With this example we can pass any struct that has an |
possibly another way to describe this is.. Just stopping by to say that this is exactly something that I was looking for. Basically, how can I avoid explicitly defining the accessors (via an interface), especially in the case when I fully intend on allowing both Get & Set to occur. I feel that gymnastics are a totally reasonable expectation when I either want only 1 of Get/Set, OR if the Get/Set needs extra explicit handling. In that case, an interface makes sense. Otherwise, it's just boilerplate. |
|
I believe that this kind of generic structural typing would be extremely useful, and necessary for systems that have performance requirements that dynamic dispatch cannot handle. That being said the above suggestions for type sets with struct members only being structural seems to be against the grain of the type set. If I were to write the follow: type Named interface {
string | struct { Name string }
}I expect the set of types to be the set that consists of string and the struct literal that Has a Name property of type string. Therefore, and this might be extremely unpopular, would it not make more sense to extend the constraint/interface syntax to allow for struct members? type Xer interface {
X int
}In the same way that This way we don't need to touch what the tilde operator means, or how to interpret type unions? Otherwise I think we would be taking two steps backwards in regards to eventually supporting sum types (if ever). EDIT: To add a more concrete scenario suppose: type Point1D { X int }
type Point2D { X, Y int }
type Point3D { X, Y, Z int }
// type constraint
type TwoDimensional interface { X, Y int }
// Works for any struct with X and Y of type int, including Point2D and Point3D, etc.
func SomePlanar2DOperation[T TwoDimensional](value T) { ... } |
|
Many interesting ideas here. But, if the use case of my original examples could work somehow, I don't mind the implementation details. |
|
I think my idea might need to be rewritten as a proposal. As far as whether common fields of a struct union should usable from the function body, I agree. But somebody who knows if it is implementable should comment. |
|
I have a real scenario where I'm working on ETL jobs that work nicely with generics. The only thing that prevents it to work is assigning a value of a Field to the struct. And since there is a lot of struct object and each has a lot of properties, adding setter / getter for each struct seems to defeat the whole purpose. |
|
It is strange that if all the structs have the same underlying type, then the code works. package main
import "fmt"
type Point struct {
X, Y, W, H int
}
type Rect struct {
X, Y, W, H int
}
type Elli struct {
X, Y, W, H int
}
func GetX[P interface { Point | Rect | Elli }] (p P) int {
return p.X
}
func main() {
p := Point { 1, 2, 0, 0}
r := Rect {2, 3, 7, 8}
e := Elli {4, 5, 9, 10}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
}However, I didn't find the [Edit], maybe the reason why it works is the constraint has a core type: https://tip.golang.org/ref/spec#Core_types |
|
Promoted fields also work (if their underlying types are the same): package main
import "fmt"
type Base struct {
X, Y, W, H int
}
type Point struct {
Base
}
type Rect struct {
Base
}
type Elli struct {
Base
}
func GetX[P interface { Point | Rect | Elli }] (p P) int {
return p.X // okay
}
func main() {
p := Point {}
r := Rect {}
e := Elli {}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
}But hybrid promoted and direct fields don't work: package main
import "fmt"
type Point struct {
X, Y, W, H int
}
type Rect struct {
Point
}
type Elli struct {
Point
}
func GetX[P interface { Point | Rect | Elli }] (p P) int {
return p.X // error: p.X undefined (type P has no field or method X)
}
func main() {
p := Point { 1, 2, 0, 0}
r := Rect {}
e := Elli {}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
} |
|
Different but with some similarity: package main
func bar[F func(int) | func(int)int] (f F) {
f(1) // invalid operation: cannot call non-function f (variable of type F constrained by func(int)|func(int) int)
}
func main() {} |
It doesn't support method access either. Playground: https://gotipplay.golang.org/p/aEwSDTXYOlL Of course method access can be solved by adding the common method to the constraint: I would like to ask
EDIT:
This quote has then been ported to the Go 1.18 specs:
Emphasis on usually, which doesn't exclude pushing into the interface's method set the intersection of the methods of the type terms. So... on a second thought, method access not working seems a bug (maybe a documentation bug). Am I misreading something? |
|
@blackgreen100 That is #51183 |
The Go 1.18 release is a huge release and we simply haven't had the bandwidth to get everything done. |
|
@blackgreen100 Note that the method set limitation is explicitly called out in the release notes (https://go.dev/doc/go1.18#generics). |
|
This isn't going to happen in Go 1.19. |
|
Whatever happens here, will not happen for 1.20. Bumping to 1.21. |
|
Just wanted to add one more anecdote to this thread. We have a few dozen types that all have a common field A common check we do is We wanted to simplify this check into a simple Of course, we could define an interface with a common getter for every single type that we have. But this would be highly redundant at this point, and the compiler should clearly be smart enough to pick up on this member being common across all types. I imagine many such use-cases exist where someone wants to do a complicated check on a struct's members, with multiple structs all having the same common members. Libraries that deal with vector math come to mind, where there may be multiple different structs that rely on a common "core" of members that require similar operations to be run on them. It does also ultimately feel like it would be more "elegant" if Anyway, just wanted to say that it would be amazing if struct members could be accessible via generic functions in 1.21 :) |
|
@griesemer Looking at this thread, there seems to be a wide consensus amongst the people in this thread that implementing this feature is a good idea. However it has been postponed several times now. It would be great if this was accepted, so this could be implemented for 1.21 |
|
I found a description in the go1.18 release note https://go.dev/doc/go1.18 : |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
btw Original example can be fixed using embedded fields: Codepackage main
import "fmt"
type xField int
func (x xField) X() int { return int(x) }
func (x *xField) SetX(newX int) { *x = xField(newX) }
type yField int
func (y yField) Y() int { return int(y) }
func (y *yField) SetY(newY int) { *y = yField(newY) }
type wField int
func (w wField) W() int { return int(w) }
func (w *wField) SetW(newW int) { *w = wField(newW) }
type hField int
func (h hField) H() int { return int(h) }
func (h *hField) SetH(newH int) { *h = hField(newH) }
type Point struct {
xField
yField
}
type Rect struct {
xField
yField
wField
hField
}
type Elli struct {
xField
yField
wField
hField
}
func GetX[P interface{ X() int }](p P) int {
return p.X()
}
func main() {
p := Point{1, 2}
r := Rect{2, 3, 7, 8}
r.SetW(8)
e := Elli{4, 5, 9, 10}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
}It is not very beautiful, but can reduce the amount of code if you need to write getters/setters. But I think the syntax |
|
Just another example for a use case and another workaround, this time without an interface.
package options
import "io"
type GetOpts struct {
url string
headers map[string]string
}
type PostOpts struct {
url string
headers map[string]string
body io.Reader
}
type opts interface{ GetOpts | PostOpts }
// Desired implementation, for now it's a compile-time error
func WithHeader[Opts opts](o Opts, k, v string) Opts {
if o.headers == nil {
o.headers = make(map[string]string)
}
o.headers[k] = v
return o
}
// With current generics, without getter/setter interfaces
// `headers` param is defined as generic only to make it easier to change
func withHeader[Opts opts, headers map[string]string](o Opts, k, v string,
getter func(Opts) headers,
setter func(*Opts, headers)) Opts {
h := getter(o)
if h == nil {
h = make(headers)
}
h[k] = v
setter(&o, h)
return o
}
// Publishing a cleaner API usage without generics, that benefits from the single implementation
// Imagine a real-world use case where the verification is more complicated (e.g. appending a value to existing key instead of overriding)
func (o PostOpts) WithHeader(k, v string) PostOpts {
return withHeader(o, k, v,
func(o PostOpts) map[string]string { return o.headers },
func(o *PostOpts, h map[string]string) { o.headers = h })
}
func (o GetOpts) WithHeader(k, v string) GetOpts {
return withHeader(o, k, v,
func(o GetOpts) map[string]string { return o.headers },
func(o *GetOpts, h map[string]string) { o.headers = h })
} |
|
On the typechecker side, the 1.21 release focuses on (much better) type inference. Didn't get to this. Moving along to 1.22. |
|
Completely new to go but here would be my use case for field access on generics: lets me use the same function wherever i need to log the details of a struct without exposing one of the fields |
The above example does not work, or am I missing something obvious. |
|
@marmiha: The above doesn't work but you can work around this by creating an interface to get/set the common base fields then using the interface as the constraint for your generic: package main
import "fmt"
type IBase interface {
GetX() int
}
type Base struct {
X, Y, W, H int
}
func (b Base) GetX() int {
return b.X
}
type Point struct {
Base
}
type Rect struct {
Base
}
type Elli struct {
Base
}
func GetX[T IBase](v T) int {
return v.GetX()
}
func main() {
p := Point{}
r := Rect{}
e := Elli{}
fmt.Printf("X: %d %d %d\n", GetX(p), GetX(r), GetX(e))
} |
ianlancetaylor
changed the title
ianlancetaylor
added
Proposal
and removed
NeedsDecision
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
and others
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
No, it is a generics issue, therefore tested with a recent tip only.
What operating system and processor architecture are you using (
go env)?linux/amd64
go envOutputWhat did you do?
I tried to compile this program (crtp.go) with generics:
with
tmp/golang-tip/bin/go buildWhat did you expect to see?
Program compiles, runs and outputs
X: 1 2 4What did you see instead?
./crtp.go:19:11: p.X undefined (type bound for P has no method X)All three structs in the type bound have an identical X /field/, so I think this is wrong. Of course there is no method but I don't think that matters here. I feel I should be able to use the public field X of p since p can only be one of the three Point, Rect, or Elli.
The text was updated successfully, but these errors were encountered: