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 · 4 comments
Open

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

griesemer opened this issue Nov 16, 2022 · 4 comments
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

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

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
@mknyszek
Copy link
Contributor

In triage, we decided this might still happen for 1.20, but if it doesn't it can be kicked to the 1.21 milestone.

@mknyszek
Copy link
Contributor

Should we kick this to 1.21?

@griesemer griesemer modified the milestones: Go1.20, Go1.21 Jan 18, 2023
@griesemer griesemer modified the milestones: Go1.21, Go1.22 Jun 1, 2023
@griesemer griesemer removed their assignment Nov 30, 2023
@griesemer
Copy link
Contributor Author

This will (probably) require a change to the recorded API text format; this is not just a simple bug fix. Leaving open for 1.22 for visibility but can be moved to 1.23. At some point we should actively work on this.

@gopherbot gopherbot modified the milestones: Go1.22, Go1.23 Feb 6, 2024
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
Development

No branches or pull requests

4 participants