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
Paragraph about T: 'static
is not right
#31
Comments
As a consequence, I'd be careful with these takeaways:
(Editing as I'm trying to make this sound less pedantic / annoying / etc., not sure if that's a succes, sorry! 😬) |
I absolutely agree with the blogpost that The syntax Thereby, the syntax Personally I read |
Bound in this context should not be confused with bound as in upperbound/lowerbounded. That is, Bound in this context should be understood as bound as in bounded set. That is, |
What would be the meaning of such a Venn diagram? If you wanted to make, for example, a Venn diagram of code lines / locations where a lifetime is valid, then it would be exactly the other way around - |
See https://doc.rust-lang.org/nomicon/subtyping.html?highlight=subtyp#subtyping-and-variance
Representing the subtype and supertype as sets as in set theory, it's clear that the set of subtype must be a subset of the set of supertype. In Venn Diagram, subset is contained insides superset. That's the correct way to understand |
Oh, I see what you mean. The set of types Still not sure about the "bound" wording, in context of Rust by "bound" I usually understand the whole clause |
If the reader interprets "If
That's not true though, I can create and drop a We could say "if Hmmm, I'm gonna think about the phrasing some more. |
Yeah, that seems perfectly fine 🙂
Well that's right
Yeah, the "outlives" terminology is kind of confusing since it's actually inclusive (ie. it's a use std::mem::MaybeUninit;
static FOO: MaybeUninit<String> = MaybeUninit::uninit(); This wouldn't be possible if Thanks for looking into this. |
TL;DR The misconception that if T: 'static then T must be valid for the entire program ... is not a misconception. It's literally true, in a sort of pedantic way.
The problem is that people conflate validity of types with lifetime of values.
The fact that a type is valid for an entire duration of a program is disctinct from whether or not there are values of that type physically existing at some point or another.
A type
T: 'static
is valid even before you create any values of it, in fact, it's valid even if it's absolutely impossible to create any values of it, such as with the!
orInfallible
or similar types.On the other hand, a non-static type can only be referred to in some part of a program where the type contains some specific lifetime, which only exists in that part of the prorgam. Again, this is distinct from any actual values of that type - those might not exist either.
As a consequence, leaking is completely unrelated to whether a type is
'static
or not, since leaking deals with values. You can leak values of non-static types just fine. I'm afraid mentioning leaking in that section only increases the confusion.Here's a demonstration of this:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3615f118612c24891f44e2e0c820d3a5
Hopefully this'll make sense. It's kind of hard to show this in an actual code, since I don't think there's a way of implementing functions for a non-static type only (there's no non-static marker trait etc.).
The text was updated successfully, but these errors were encountered: