go/types, types2: disable field accesses through type parameters for now

[griesemer]

Field accesses through type parameters have been implemented and work, but are currently restricted to type parameters that have a core type.

This code

func g[P interface {
    struct{ f int }
    f() int
}](x P) {
    _ = x.f()
}

is currently accepted (as expected) because we don't determine that the type set for P is empty (the intersection of the single type struct{ f int } and the set of types that have method f() int is empty). We could change the embedded type element to ~struct{ f int } but in that case we cannot instantiate P because it's not possible to have a struct type with a field and a method with the same name.

This code

type F struct {
    f int
}

func g[P interface {
    ~struct{ F }
    f() int
}](x P) {
    _ = x.f()
}

is also accepted (as expected). Here it is possible to instantiate P because the field f and the method f are at different depths.

Note that in pre-1.18 Go, field and method names for a struct must be different (at the same level of embedding). It is not clear what the rules should be here.

These are just some of the questions that are brought up by this mechanism.

The current implementation could be described in the spec as follows:

Given a selector x.f, look up f following the usual rules. If no f is found, and if x is of type parameter type with a core type, look up f again on that core type and return that result, but only if it's a field.

It's not obviously clear if the generalization beyond core types (x.f is valid if it's valid for all types in a type set) will not lead to subtle surprises in behavior. We don't know if we should have restrictions with respect to method and field names that are the same. And so on.

In summary, while we do have an implementation, we don't fully understand the repercussions of this feature and how it would affect its generalization. At the same time we can always use methods as field accessors so there is a reasonable work-around.

The prudent decision for Go 1.18 is to disable this feature until we understand it well. We don't want to be in a situation where we have to support a potentially flawed mechanism for backward-compatibility.

[gopherbot]

Change https://go.dev/cl/391135 mentions this issue: go/types, types2: disable field accesses through type parameters

[gopherbot]

Change https://go.dev/cl/391137 mentions this issue: spec: remove note re: field accesses on type literals

[gopherbot]

Change https://go.dev/cl/391274 mentions this issue: [release-branch.go1.18] doc/go1.18: document field access limitations for type parameters

[gopherbot]

Change https://go.dev/cl/391279 mentions this issue: _content/doc: update Go 1.18 release notes

[gopherbot]

Change https://go.dev/cl/391355 mentions this issue: [release-branch.go1.18] go/types, types2: disable field accesses through type parameters

[bitfield]

By 'disable this feature', do you mean that it won't be possible to access the fields of a type parameter at all? So this example would no longer be valid: https://go.dev/play/p/bJ1QGu1MU38?v=gotip

[griesemer]

@bitfield That is correct, your example doesn't work anymore (at least for Go 1.18). You can always use a method on the struct and the constraint. (As an aside, I have yet to see a convincing example for why this mechanism is crucial; especially because methods permit a work-around.)

There are simply too many unanswered questions around this mechanism for which we don't have solid answers yet. We don't want to be locked in through the backward compatibility guarantee if we make a mistake here. Note that the rules around field access are among the most subtle and complicated in the language spec and the implementation, even though for a user it may look "simple". Thanks.

[bitfield]

That's fine, thanks—I just wanted to clarify exactly what this change implies. I don't have a convincing use case for this either, but I'm looking at it from a writer's/teacher's point of view. It seems to be quite natural for people to try this quite early on when experimenting with constraints, and I need to be able to explain to them why this apparently straightforward thing isn't allowed. It looks easy from the programmer's side, if you see what I mean. "I know my parameter is a struct with these exact fields, why can't I access them?"

No writer likes to have to say "Here's something you can't do!" But I think it's going to be important to get out ahead of those inevitable questions.