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

Add an attribute for asserting variance of generic parameters #72926

Open
Aaron1011 opened this issue Jun 2, 2020 · 1 comment
Open

Add an attribute for asserting variance of generic parameters #72926

Aaron1011 opened this issue Jun 2, 2020 · 1 comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@Aaron1011
Copy link
Member

Currently, we don't have any kind of programmatic way of ensuring that we don't accidentally change the variances of any libcore/libstd types. While some types do have explicit tests for variance (e.g. here and in PR #72902), this is not done in any kind of systematic way.

I think it would be useful to have an internal #[variance(Co/Contra/In)] (names bikesheddable) which causes an error if the actual and expected variances do not match.

We could require that every generic parameter on every public type have a #[variance] attribute, similar to how we require #[stable]/#[unstable]. However, this could end up being unnecessarily verbose, especially if most types are covariant. Instead, we might want to treat the absence of a #[variance] annotation as an implicit #[variance(Covariant)] (or #[variance(Invariant)] for const generics). If covariance is normally what we want, then this would only require us to annotate cases where something 'unusual' is happening. Of course, we would run the risk of cases like #71814 'slipping under the radar', where the generic parameter really should have been invariant to begin with.

@Aaron1011 Aaron1011 added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 2, 2020
@lcnr
Copy link
Contributor

lcnr commented Jun 3, 2020

where the generic parameter really should have been invariant to begin with.

Not completely relevant to this issue, but I disagree here. Discriminant would still be completely sound even if it were bivariant, which it should be IMO.

Apart from this, I do agree that we should have an easy way to guard against variance changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

2 participants