4 ms·

The wording that "'static means different things" is a bit misleading. It means the same thing, but the meaning different because of the context: Lifetime: lif

The wording that "'static means different things" is a bit misleading. It means the same thing, but the meaning different because of the context: Lifetime: lifetime means that the first lifetime outlives (is as long or longer) the second Type: lifetime means that the type is constrained by the lifetime. Because 'static means "the lifetime of the whole process". That means that the type is not constrained.

wokwokwok 6y ago
I find it very confusing. T: ‘a is T outlives ‘a; but types are not generated at runtime. All types are static; which is to say they are created at compile time and exist for the lifetime of the program. Or does rust generate type variants on the fly at runtime? I didn’t think it did... It is a constraint applied to arguments at compile time... but r, that’s what I thought anyway.
- dbaupp 6y ago
  A type constraint like T: ‘a or T: Trait is constraining values of type T, not the type T itself. That is T: ‘a is saying “all references in values of type T live at least as long as ‘a”. This includes ‘a = ‘static and the vacuous case of T containing no references.
- DougBTX 6y ago
  > T: ‘a is T outlives ‘a; but types are not generated at runtime. Yes, that’s true, but you can make it a bit more specific by saying “all the references in T outlive ‘a”. Then it should make more sense, as references are generated at runtime. This gets to the heart of what makes Rust an interesting language, as references are generated at runtime, but how long those references are valid for is checked at compile time using lifetime bounds.
- kaoD 6y ago
  Types are not generated at runtime, lifetimes are types (although they cannot be constructed). T<'a> and T<'b> are different types altogether (although, being generic, they can resolve to the same type if 'a == 'b, but it's not required). All this happens at compile time. When you say T: 'a you say that T is a subtype of 'a hence it lives longer. https://doc.rust-lang.org/nomicon/subtyping.html https://doc.rust-lang.org/nomicon/subtyping.html Maybe you're being confused by misconception 1 here? https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md https://github.com/pretzelhammer/rust-blog/blob/master/posts... Type T, being generic, can be an OwnedStruct, but also an &'a BorrowedStruct or a StructWithReferences<'a>. The owned one is a subtype of 'static since it's owned, but the ones with lifetimes are subtypes of 'a which itself (being a generic lifetime) can be a subtype of 'static or any other lifetime. Again, all this happens and is checked at compile time. This ensures that at runtime, the actual references are alive as per their lifetimes without explicitly checking them anymore.
  - wokwokwok 6y ago
    You misunderstand; what confuses me is how 'static can mean the same thing in both of these contexts. T: 'static does not mean the references in T must exist for the lifetime of the application. Ie. the lifetime constraint on T isn’t the same 'static from &'static where the reference must life for the entire lifetime of the application. Types are static. T: 'static applies to instances at runtime. These instances do not have and are not related to the 'static lifetime which is “the entire length of the application”. I accept: > Type: lifetime means that the type is constrained by the lifetime. I don't accept the explanation: > Because 'static means "the lifetime of the whole process". That means that the type is not constrained. A does not follow from B. If you want something to mean "A type cannot have references in it" then invent a 'noref lifetime. 'static in this context would mean that all members of T must be 'static, which means that all instances of T must be 'static. It does not mean that. I don’t understand why they have the same name; they are not the same thing; it is an example of failure to have orthogonality in the language design in my opinion.
    - kaoD 6y ago
      Sorry, I probably edited my comment while you were replying and added a couple links. Check misconception 2 here, I think it addresses your point. https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md#2-if-t-static-then-t-must-be-valid-for-the-entire-program https://github.com/pretzelhammer/rust-blog/blob/master/posts... EDIT to your edit: > 'static in this context would mean that all instances of T must be 'static. You mean in T: 'static? No. It means that any instance passed as type T must be bound by 'static and therefore could be held up to the end of 'static. This does not mean that they're allocated at compile time, it just so happens that static variables (allocated at compile time) are 'static but the causality is reversed. > If you want something to mean "A type cannot have references in it" then invent a 'noref lifetime. It can have references in it! As long as they're bound by 'static. Here's an example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=857389cd5251e037f5ba608566b89b04 https://play.rust-lang.org/?version=stable&mode=debug&editio...
      - deleted 6y ago

wokwokwok 6y ago

I find it very confusing. T: ‘a is T outlives ‘a; but types are not generated at runtime. All types are static; which is to say they are created at compile time and exist for the lifetime of the program. Or does rust generate type variants on the fly at runtime? I didn’t think it did... It is a constraint applied to arguments at compile time... but r, that’s what I thought anyway.

dbaupp 6y ago
A type constraint like T: ‘a or T: Trait is constraining values of type T, not the type T itself. That is T: ‘a is saying “all references in values of type T live at least as long as ‘a”. This includes ‘a = ‘static and the vacuous case of T containing no references.
DougBTX 6y ago
> T: ‘a is T outlives ‘a; but types are not generated at runtime. Yes, that’s true, but you can make it a bit more specific by saying “all the references in T outlive ‘a”. Then it should make more sense, as references are generated at runtime. This gets to the heart of what makes Rust an interesting language, as references are generated at runtime, but how long those references are valid for is checked at compile time using lifetime bounds.
kaoD 6y ago
Types are not generated at runtime, lifetimes are types (although they cannot be constructed). T<'a> and T<'b> are different types altogether (although, being generic, they can resolve to the same type if 'a == 'b, but it's not required). All this happens at compile time. When you say T: 'a you say that T is a subtype of 'a hence it lives longer. https://doc.rust-lang.org/nomicon/subtyping.html https://doc.rust-lang.org/nomicon/subtyping.html Maybe you're being confused by misconception 1 here? https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md https://github.com/pretzelhammer/rust-blog/blob/master/posts... Type T, being generic, can be an OwnedStruct, but also an &'a BorrowedStruct or a StructWithReferences<'a>. The owned one is a subtype of 'static since it's owned, but the ones with lifetimes are subtypes of 'a which itself (being a generic lifetime) can be a subtype of 'static or any other lifetime. Again, all this happens and is checked at compile time. This ensures that at runtime, the actual references are alive as per their lifetimes without explicitly checking them anymore.
- wokwokwok 6y ago
  You misunderstand; what confuses me is how 'static can mean the same thing in both of these contexts. T: 'static does not mean the references in T must exist for the lifetime of the application. Ie. the lifetime constraint on T isn’t the same 'static from &'static where the reference must life for the entire lifetime of the application. Types are static. T: 'static applies to instances at runtime. These instances do not have and are not related to the 'static lifetime which is “the entire length of the application”. I accept: > Type: lifetime means that the type is constrained by the lifetime. I don't accept the explanation: > Because 'static means "the lifetime of the whole process". That means that the type is not constrained. A does not follow from B. If you want something to mean "A type cannot have references in it" then invent a 'noref lifetime. 'static in this context would mean that all members of T must be 'static, which means that all instances of T must be 'static. It does not mean that. I don’t understand why they have the same name; they are not the same thing; it is an example of failure to have orthogonality in the language design in my opinion.
  - kaoD 6y ago
    Sorry, I probably edited my comment while you were replying and added a couple links. Check misconception 2 here, I think it addresses your point. https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md#2-if-t-static-then-t-must-be-valid-for-the-entire-program https://github.com/pretzelhammer/rust-blog/blob/master/posts... EDIT to your edit: > 'static in this context would mean that all instances of T must be 'static. You mean in T: 'static? No. It means that any instance passed as type T must be bound by 'static and therefore could be held up to the end of 'static. This does not mean that they're allocated at compile time, it just so happens that static variables (allocated at compile time) are 'static but the causality is reversed. > If you want something to mean "A type cannot have references in it" then invent a 'noref lifetime. It can have references in it! As long as they're bound by 'static. Here's an example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=857389cd5251e037f5ba608566b89b04 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - deleted 6y ago