Skip to content
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

cmd/compile: embedded field type cannot be a (pointer to a) type parameter #49030

Closed
Fullstop000 opened this issue Oct 18, 2021 · 4 comments
Closed
Assignees
Milestone

Comments

@Fullstop000
Copy link

@Fullstop000 Fullstop000 commented Oct 18, 2021

What version of Go are you using (go version)?

go version devel go1.18-cf51fb5d68 Sun Oct 17 04:27:13 2021 +0000 darwin/amd64

In https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md, the following code should be ok to be compiled:

type Lockable[T any] struct {
	T
	mu sync.Mutex
}

// Get returns the value stored in a Lockable.
func (l *Lockable[T]) Get() T {
	l.mu.Lock()
	defer l.mu.Unlock()
	return l.T
}

// Set sets the value in a Lockable.
func (l *Lockable[T]) Set(v T) {
	l.mu.Lock()
	defer l.mu.Unlock()
	l.T = v
}

What did you expect to see?

compile success

What did you see instead?

~/dev/go2playground ~/goroot/bin/go test
# go2playground [go2playground.test]
./main_test.go:50:2: embedded field type cannot be a (pointer to a) type parameter
@randall77
Copy link
Contributor

@randall77 randall77 commented Oct 18, 2021

Loading

@cherrymui cherrymui added this to the Go1.18 milestone Oct 18, 2021
@cherrymui cherrymui changed the title embedded field type cannot be a (pointer to a) type parameter cmd/compile: embedded field type cannot be a (pointer to a) type parameter Oct 18, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 18, 2021

We tentatively concluded that embedding type parameters may not be permitted initially because of questions re: method promotion. The same questions arise with a pointer to a type parameter. But perhaps we can allow this after all.

Will reconsider.

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 29, 2021

We've talked about this again, and we're not going to change this for 1.18. Reasons:

  • There are open questions with respect to what the type of such an embedded field would be. Consider also the case:
func f[P constraint]() {
   type S struct{
      P // <<< should this be permitted?
   }
   ...
}
  • There are open questions with respect to method promotion.
  • We can always add it later, but we won't be able to remove the feature if we make a mistake.
  • The implementation is already restricted; making changes such as this shortly before the code freeze is risky.

The fact that the generics proposal still describes this possibility is simply an oversight. Eventually the spec (in progress) will be the final guiding document.

Closing. Once we have gained more experience with type parameters we can reconsider this as a proposal.

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 29, 2021

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants