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/api: api checker should check types for change in comparability #56773

Open
griesemer opened this issue Nov 16, 2022 · 1 comment
Open

cmd/api: api checker should check types for change in comparability #56773

griesemer opened this issue Nov 16, 2022 · 1 comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@griesemer
Copy link
Contributor

griesemer commented Nov 16, 2022

The api checker checks that we don't change our APIs in a backward-incompatible way.

Generics introduced the constraint comparable which denotes the set of all types which are strictly comparable. An API may define an exported type T which may be strictly comparable (see #56548 for terminology) and such a type T may successfully be used as type argument for comparable type parameters elsewhere.

It's possible to change T without visible API change so that it's not strictly comparable anymore. For instance, given

// T is strictly comparable
type T struct {
   /* exported and unexported fields which are all strictly comparable */
}

one can add a new, unexported field that is not strictly comparable

// T is not strictly comparable anymore
type T struct {
   /* exported and unexported fields which are all strictly comparable */
   unexported any // not strictly comparable
}

The visible API has not changed but T is not not strictly comparable anymore. This may prevent it's use elsewhere.

The api checker should treat such changes as API changes.

Marking for 1.20 as it would be a useful check and could be added late in the cycle.

@griesemer griesemer added this to the Go1.20 milestone Nov 16, 2022
@griesemer
Copy link
Contributor Author

griesemer commented Nov 16, 2022

See this example for a mechanism that library writers can use to assert strict comparability of exported types they care about.

@joedian joedian added compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: No status
Development

No branches or pull requests

2 participants