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/go: type set overlapping implementation for interface types might be not correct #51607

Closed
go101 opened this issue Mar 11, 2022 · 9 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@go101
Copy link

go101 commented Mar 11, 2022

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

$ go version
go version go1.18rc1 linux/amd64

What did you do?

// okay
type C1 interface {
	interface {bool | int} | interface {bool | string}
}

// okay
type C2 interface {
	interface {bool | int} ; interface {bool | string}
}

// okay
type C3 interface {
	interface {bool; int} ; interface {bool; string}
}

// error: overlapping terms interface{bool; string} and interface{bool; int}
type C4 interface {
	interface {bool; int} | interface {bool; string}
}

What did you expect to see?

C1 contains overlapping. C4 doesn't.

What did you see instead?

Neither is true thought by the compiler.

@ianlancetaylor ianlancetaylor changed the title cmd/go: type set overlapping implementaiton for interface types might be not correct cmd/go: type set overlapping implementation for interface types might be not correct Mar 11, 2022
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 11, 2022
@ianlancetaylor ianlancetaylor added this to the Go1.19 milestone Mar 11, 2022
@ianlancetaylor
Copy link
Contributor

The rule about overlapping type sets only applies to unions, so C2 and C3 are OK. The rule only applies to non-interface types, so C1 is OK. And for that matter C4 is OK too for the same reason. I'm not sure why the compiler would give an error for that.

This doesn't matter for 1.18, especially since for C4 the type sets are empty anyhow. We can fix this one way or the other for 1.19.

CC @griesemer

@griesemer griesemer self-assigned this Mar 11, 2022
@griesemer
Copy link
Contributor

Pretty esoteric case. This can wait even past 1.19 if need be.

@go101
Copy link
Author

go101 commented Mar 11, 2022

The rule for non-interface might be unnecessary, for each solo term could be enclosed in interface{ ... }.

[Edit]: for example

type C1 interface {
	int | ~int // error
}

type C2 interface {
	interface {int} | interface {~int} // okay
}

@gopherbot
Copy link

Change https://go.dev/cl/397514 mentions this issue: types2: fix overlap test for union termlist

@gopherbot
Copy link

Change https://go.dev/cl/397695 mentions this issue: types2: fix overlap test for union termlist

@go101
Copy link
Author

go101 commented Apr 2, 2022

It looks overlapping is hard to removed totally.

type Ptr[T any] *T

type MyConstraint[E any] interface {
	Ptr[int] | Ptr[E]
}

type YourConstraint MyConstraint[int] // okay

@griesemer
Copy link
Contributor

@go101 That is ok. We identify overlaps as errors because most likely they indicate a programmer error: e.g., code that says ~int|MyInt (where the underlying type of MyInt is int) is likely the result of not fully understanding the effect of the constraint, which is why we point it out. Similar to how we point out duplicate explicit method entries in an interface. But we accept duplicate method entries through embedding of interfaces, and so do we accept duplicate/overlapping type elements through interfaces in unions. For parameterized types we can't say anything before use, and that's ok.

@griesemer
Copy link
Contributor

@gopherbot please backport to 1.18, this bug leads to confusing and misleading errors, and the fix is straight-forward.

@gopherbot
Copy link

Backport issue(s) opened: #52119 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants