Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Add an extra fn() entry to the variance table in the subtyping chapter #874
Conversation
While discussing variance on a Rust help channel, I noticed that the subtyping chapter does not specifically mention the special case where a type parameter is used both in the input and output of a function, which, as far as I know, would make it be treated as invariant because its the intersection of both contravariance and covariance. In case I'm not totally wrong with this, I propose adding that case to the table to make it a bit more clear.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
While discussing variance on a Rust help channel, I noticed that the subtyping chapter does not specifically mention the special case where a type parameter is used both in the input and output of a function, which, as far as I know, would make it be treated as invariant because its the intersection of both contravariance and covariance.
In case I'm not totally wrong with this, I propose adding that case to the table to make it a bit more clear.