Good, it doesn't compile! Let's break down what's happening here in detail.
Good, it doesn't compile! Let's break down what's happening here in detail.
First let's look at the new `evil_feeder` function:
First let's look at the `assign` function:
```rust
```rust
fn evil_feeder<T>(input: &mut T, val: T) {
fn assign<T>(input: &mut T, val: T) {
*input = val;
*input = val;
}
}
```
```
@ -315,60 +221,43 @@ All it does is take a mutable reference and a value and overwrite the referent w
What's important about this function is that it creates a type equality constraint. It
What's important about this function is that it creates a type equality constraint. It
clearly says in its signature the referent and the value must be the *exact same* type.
clearly says in its signature the referent and the value must be the *exact same* type.
Meanwhile, in the caller we pass in `&mut &'static str` and `&'spike_str str`.
Meanwhile, in the caller we pass in `&mut &'static str` and `&'world str`.
Because `&mut T` is invariant over `T`, the compiler concludes it can't apply any subtyping
Because `&mut T` is invariant over `T`, the compiler concludes it can't apply any subtyping
to the first argument, and so `T` must be exactly `&'static str`.
to the first argument, and so `T` must be exactly `&'static str`.
The other argument is only an `&'a str`, which *is* covariant over `'a`. So the compiler
This is counter to the `&T` case:
adopts a constraint: `&'spike_str str` must be a subtype of `&'static str` (inclusive),
which in turn implies `'spike_str` must be a subtype of `'static` (inclusive). Which is to say,
`'spike_str` must contain `'static`. But only one thing contains `'static` -- `'static` itself!
This is why we get an error when we try to assign `&spike` to `spike_str`. The
```rust
compiler has worked backwards to conclude `spike_str` must live forever, and `&spike`
fn debug<T:std::fmt::Debug>(a: T, b: T) {
simply can't live that long.
println!("a = {a:?} b = {b:?}");
}
```
So even though references are covariant over their lifetimes, they "inherit" invariance
where similarly `a` and `b` must have the same type `T`.
whenever they're put into a context that could do something bad with that. In this case,
But since `&'a T`*is* covariant over `'a`, we are allowed to perform subtyping.
we inherited invariance as soon as we put our reference inside an `&mut T`.
So the compiler decides that `&'static str` can become `&'b str` if and only if
`&'static str` is a subtype of `&'b str`, which will hold if `'static <: 'b`.
This is true, so the compiler is happy to continue compiling this code.
As it turns out, the argument for why it's ok for Box (and Vec, Hashmap, etc.) to
As it turns out, the argument for why it's ok for Box (and Vec, HashMap, etc.) to be covariant is pretty similar to the argument for why it's ok for lifetimes to be covariant: as soon as you try to stuff them in something like a mutable reference, they inherit invariance and you're prevented from doing anything bad.
be covariant is pretty similar to the argument for why it's ok for
references to be covariant: as soon as you try to stuff them in something like a
mutable reference, they inherit invariance and you're prevented from doing anything
bad.
However, Box makes it easier to focus on the by-value aspect of references that we
However Box makes it easier to focus on the by-value aspect of references that we partially glossed over.
partially glossed over.
Unlike a lot of languages which allow values to be freely aliased at all times,
Unlike a lot of languages which allow values to be freely aliased at all times, Rust has a very strict rule: if you're allowed to mutate or move a value, you are guaranteed to be the only one with access to it.
Rust has a very strict rule: if you're allowed to mutate or move a value, you
are guaranteed to be the only one with access to it.
Consider the following code:
Consider the following code:
<!-- ignore: simplified code -->
```rust,ignore
```rust,ignore
let mr_snuggles: Box<Cat> = ..;
let hello: Box<&'static str> = Box::new("hello");
let spike: Box<Dog> = ..;
let mut pet: Box<Animal>;
let mut world: Box<&'b str>;
pet = mr_snuggles;
world = hello;
pet = spike;
```
```
There is no problem at all with the fact that we have forgotten that `mr_snuggles` was a Cat,
There is no problem at all with the fact that we have forgotten that `hello` was alive for `'static`,
or that we overwrote him with a Dog, because as soon as we moved mr_snuggles to a variable
because as soon as we moved `hello` to a variable that only knew it was alive for `'b`,
that only knew he was an Animal, **we destroyed the only thing in the universe that
**we destroyed the only thing in the universe that remembered it lived for longer**!
remembered he was a Cat**!
In contrast to the argument about immutable references being soundly covariant because they
don't let you change anything, owned values can be covariant because they make you
change *everything*. There is no connection between old locations and new locations.
Applying by-value subtyping is an irreversible act of knowledge destruction, and
without any memory of how things used to be, no one can be tricked into acting on
that old information!
Only one thing left to explain: function pointers.
Only one thing left to explain: function pointers.
@ -376,43 +265,78 @@ To see why `fn(T) -> U` should be covariant over `U`, consider the following sig
<!-- ignore: simplified code -->
<!-- ignore: simplified code -->
```rust,ignore
```rust,ignore
fn get_animal() -> Animal;
fn get_str() -> &'a str;
```
```
This function claims to produce an Animal. As such, it is perfectly valid to
This function claims to produce a`str` bound by some liftime `'a`. As such, it is perfectly valid to
provide a function with the following signature instead:
provide a function with the following signature instead:
<!-- ignore: simplified code -->
<!-- ignore: simplified code -->
```rust,ignore
```rust,ignore
fn get_animal() -> Cat;
fn get_static() -> &'static str;
```
```
After all, Cats are Animals, so always producing a Cat is a perfectly valid way
So when the function is called, all it's expecting is a `&str` which lives at least the lifetime of `'a`,
to produce Animals. Or to relate it back to real Rust: if we need a function
it doesn't matter if the value actually lives longer.
that is supposed to produce something that lives for `'short`, it's perfectly
fine for it to produce something that lives for `'long`. We don't care, we can
just forget that fact.
However, the same logic does not apply to *arguments*. Consider trying to satisfy:
However, the same logic does not apply to *arguments*. Consider trying to satisfy:
<!-- ignore: simplified code -->
<!-- ignore: simplified code -->
```rust,ignore
```rust,ignore
fn handle_animal(Animal);
fn store_ref(&'a str);
```
```
with:
with:
<!-- ignore: simplified code -->
<!-- ignore: simplified code -->
```rust,ignore
```rust,ignore
fn handle_animal(Cat);
fn store_static(&'static str);
```
```
The first function can accept Dogs, but the second function absolutely can't.
The first function can accept any string reference as long as it lives at least for `'a`,
but the second cannot accept a string reference that lives for any duration less than `'static`,
which would cause a conflict.
Covariance doesn't work here. But if we flip it around, it actually *does*
Covariance doesn't work here. But if we flip it around, it actually *does*
work! If we need a function that can handle Cats, a function that can handle *any*
work! If we need a function that can handle `&'static str`, a function that can handle *any* reference lifetime
Animal will surely work fine. Or to relate it back to real Rust: if we need a
will surely work fine.
function that can handle anything that lives for at least `'long`, it's perfectly
fine for it to be able to handle anything that lives for at least `'short`.
Eric Huss
2 years ago
committed by
GitHub