12

I'm trying to grok lifetimes in Rust and asked myself whether they are "just" a safety measure (and a way to communicate how safety is ensured, or not, in the case of errors) or if there are cases where different choices of lifetimes actually change how the program runs, i.e. whether lifetimes make a semantic difference to the compiled program.

And with "lifetimes" I refer to all the pesky little 'a, 'b, 'static markers we include to make the borrow checker happy. Of course, writing 

{
    let foo = File::open("foo.txt")?;
} 
foo.write_all(b"bar");

instead of

let foo = File::open("foo.txt")?;
foo.write_all(b"bar");

will close the file descriptor before the write occurs, even if we could access foo afterwards, but that kind of scoping and destructor-calling also happens in C++.

Kornel
  • 97,764
  • 37
  • 219
  • 309
Perseids
  • 12,584
  • 5
  • 40
  • 64

1 Answers1

17

No, lifetimes do not affect the generated machine code in any way. At the end of the day, it's all "just pointers" to the compiled code.

Because we are humans speaking a human language, we tend to lump two different but related concepts together: concrete lifetimes and generic lifetime parameters.

All programming languages have concrete lifetimes. That just corresponds to when a resource will be released. That's what your example shows and indeed, C++ works the same as Rust does there. This is often known as Resource Acquisition Is Initialization (RAII). Garbage-collected languages have lifetimes too, but they can be harder to nail down exactly when they end.

What makes Rust neat in this area are the generic lifetime parameters, the things we know as 'a or 'static. These allow the compiler to track the underlying pointers so that the programmer doesn't need to worry if the pointer will remain valid long enough. This works for storing references in structs and passing them to and from functions.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
  • The distinction between concrete lifetimes and generic lifetime parameters is really helpful. Using the same words for both, the explanations I've so far read also mix together both *concepts*. – Perseids Sep 02 '15 at 19:04
  • @Perseids speaking honestly, I'm not sure that these are the accepted terms, but I'm doing my best to make them so. ^_^ I'm also trying to be better about saying one or the other when they are ambiguous, but it's so darned convenient to just say "lifetime". – Shepmaster Sep 02 '15 at 19:06
  • 4
    We may be getting into the weeds here, but it may be useful to clarify the statement that all programming languages have concrete lifetimes. When using garbage collection, lifetimes can actually be *dynamically* extended, which is not the case with lifetimes as described by Rust's lifetime parameters, which are solely compile-time constructs (you'd have to use something like the `Rc` pointer for dynamic lifetime extension like you'd get in a garbage collected language). – B. Striegel Sep 02 '15 at 21:36
  • 1
    @B.Striegel: Without reaching for `Rc`, the buffer of `String` can see its lifetime "extended" when the `String` is returned. – Matthieu M. Sep 03 '15 at 06:46