4 ms·

I don't know where you got this idea but this is wrong. > you use the item longer, you have a longer implicit lifetime. The memory it references will also be c

I don't know where you got this idea but this is wrong. > you use the item longer, you have a longer implicit lifetime. The memory it references will also be claimed for longer This is only true at the stack frame level, you cannot extend a variable beyond that, and there's no difference with a GC in that particular case (a GC will never remove an element for which there's a variable on the stack pointing towards it) > You only fix that by explicitly considering lifetimes as you write your code Lifetime parameters don't alter the the behavior, and their are either mandatory if the situation is ambiguous or entirely redundant. And it only works at the function boundaries, where lifetime extension cannot happen anyway. (See above) Please stop spreading bullshit criticism that have no grounding in reality (Rust has real defects like everything else, but spreading nonesense isn't OK).

hansvm 2y ago
Who said anything about extending "variables"? If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. It's not "bullshit [with] no grounding in reality." That property is, yes, what you would see in a GC language (e.g., Entity Framework back in the day in C# would have a leak if you tried to create short-lived objects from long-lived objects using the built-in DI, since EF had a bug maintaining a strong reference to those objects tied to the lifetime of the outer object). My observation is that people tend to do that much more in Rust than in GC languages because the compiler makes other coding patterns harder.
- deleted 2y ago
  [deleted]
- steveklabnik 2y ago
  Rust does not keep variables alive until references are gone. It checks to make sure that any reference lives as long as or shorter than its referent. If the reference is longer lived than the referent, that’s a compile error.
- littlestymaar 2y ago
  > Who said anything about extending "variables"? I did, because that's the only thing that can be kept alive longer than needed (till the end of the scope where the variable is defined). > If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. No it doesn't. And it shows you have no understanding of how Rust works. A GC will do that, but the borrow checker won't, it cannot, all it can do is to yell at you so that you make your variable live as long as it needs. See this playground to see what happen when you allocate something on the heap and try return a reference to it: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=130bcebf379dbb10dd4b51e649ed83bf https://play.rust-lang.org/?version=stable&mode=debug&editio... If you could please stop spreading nonsense about a language you don't even know the basics of, that would be great for everyone.
- MeetingsBrowser 2y ago
  Can you share a rust playground link with an example of what you are describing? I still don’t follow how a reference can extend the lifetime of some memory, even on the heap. Sounds like you are describing a language that uses reference counting to manage memory, and I’m not sure what purpose a borrow checker would serve in a reference counted language.

hansvm 2y ago

Who said anything about extending "variables"? If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. It's not "bullshit [with] no grounding in reality." That property is, yes, what you would see in a GC language (e.g., Entity Framework back in the day in C# would have a leak if you tried to create short-lived objects from long-lived objects using the built-in DI, since EF had a bug maintaining a strong reference to those objects tied to the lifetime of the outer object). My observation is that people tend to do that much more in Rust than in GC languages because the compiler makes other coding patterns harder.

deleted 2y ago
[deleted]
steveklabnik 2y ago
Rust does not keep variables alive until references are gone. It checks to make sure that any reference lives as long as or shorter than its referent. If the reference is longer lived than the referent, that’s a compile error.
littlestymaar 2y ago
> Who said anything about extending "variables"? I did, because that's the only thing that can be kept alive longer than needed (till the end of the scope where the variable is defined). > If you heap allocate something and store a reference to it, Rust will absolutely keep that object alive till all such references are gone. No it doesn't. And it shows you have no understanding of how Rust works. A GC will do that, but the borrow checker won't, it cannot, all it can do is to yell at you so that you make your variable live as long as it needs. See this playground to see what happen when you allocate something on the heap and try return a reference to it: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=130bcebf379dbb10dd4b51e649ed83bf https://play.rust-lang.org/?version=stable&mode=debug&editio... If you could please stop spreading nonsense about a language you don't even know the basics of, that would be great for everyone.
MeetingsBrowser 2y ago
Can you share a rust playground link with an example of what you are describing? I still don’t follow how a reference can extend the lifetime of some memory, even on the heap. Sounds like you are describing a language that uses reference counting to manage memory, and I’m not sure what purpose a borrow checker would serve in a reference counted language.