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

go/types, cmd/compile/internal/types2: disallow local declarations and aliases of type parameters #45639

Open
findleyr opened this issue Apr 19, 2021 · 5 comments
Assignees
Milestone

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Apr 19, 2021

Consider the following snippet, with annotated type checking error.

type xer interface {
        x() string
}

func Print[T xer](s []T) {
        type Y T
        for _, v := range s {
                fmt.Println(v.x())
        }
        var y Y
        y.x() // <-- ERROR "y.x undefined (interface xer has no method x)"
}

This error is both inaccurate and (as a secondary concern) fails to mention the named type Y.

Update: per discussion below, let's disallow such declarations (as well as type Y = T) for now.

CC @griesemer

@findleyr findleyr added this to the Go1.18 milestone Apr 19, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 19, 2021

Change https://golang.org/cl/311455 mentions this issue: go/types: support type parameters in NewMethodSet

@griesemer griesemer self-assigned this Apr 19, 2021
@griesemer
Copy link
Contributor

@griesemer griesemer commented Apr 19, 2021

Our proposals do not explain what Y should be. Should it be a type parameter? Or an interface? Maybe it shouldn't be permitted.

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Apr 19, 2021

Yes, sorry to be clear the problem here may only be the misleading error message. I wasn't sure.

I think we should either allow Y to have a type parameter as its underlying type (and remove the guard against type parameters in rawLookupFieldOrMethod), or make it an error to declare such a Y. I think it would be more confusing to make Y an interface, as then we'd lose convertibility: var y Y; t := T(y) would be invalid.

Perhaps in the absence of any reason to write this code, we should err on the side of caution and disallow such a declaration (at least for now).

@griesemer
Copy link
Contributor

@griesemer griesemer commented Apr 19, 2021

Let's disallow it for now. Same for local aliases of type parameters (even though those shouldn't be a problem, I think).

@findleyr findleyr changed the title go/types, cmd/compile/internal/types2: bad method lookup for named type with type parameter underlying go/types, cmd/compile/internal/types2: disallow local declaration and aliasing of type parameters Apr 20, 2021
@findleyr findleyr changed the title go/types, cmd/compile/internal/types2: disallow local declaration and aliasing of type parameters go/types, cmd/compile/internal/types2: disallow local declarations and aliases of type parameters Apr 20, 2021
@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Apr 20, 2021

Let's disallow it for now. Same for local aliases of type parameters

Sounds good. Updated the issue accordingly.

gopherbot pushed a commit that referenced this issue Apr 20, 2021
Add handling for TypeParams in NewMethodSet, to bring it in sync with
lookupFieldOrMethod. Also add a test, since we had none. I wanted this
fix to get gopls completion working with type params, but due to the
subtlety of lookupFieldOrMethod, I left a TODO to confirm that there are
no behavioral differences between the APIs.

Updates #45639

Change-Id: I16723e16d4d944ca4ecb4d87fc196815abb6fcff
Reviewed-on: https://go-review.googlesource.com/c/go/+/311455
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
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
@griesemer @gopherbot @findleyr and others