
Non-Lexical Lifetimes Based on Liveness in Rust - killercup
http://smallcultfollowing.com/babysteps/blog/2016/05/04/non-lexical-lifetimes-based-on-liveness/
======
killercup
The introductory post [1] was also discussed here [2].

[1]:
[http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...](http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-
lexical-lifetimes-introduction/) [2]:
[https://news.ycombinator.com/item?id=11611436](https://news.ycombinator.com/item?id=11611436)

------
sspiff
I wonder how clear error messages for this kind of liveness checking will be.
Will they be able to point to variable usage that causes a variable to be
locked?

~~~
chrismorgan
The Rust team is committed to having high-quality error messages in rustc, and
its lifetime error messages are singularly superb, making a complex concept
understandable and explaining in very thorough detail when necessary what is
causing a problem: “this expected this because of this but found this which
would mean that instead” with detailed diagnostics of the points in question,
and such things.

This tradition will not be forsaken with non-lexical lifetimes.

------
JulianMorrison
This strikes me as a bad idea prone to action-at-a-distance.

    
    
      let a = 1
      let b = pointer to a
      do_stuff(b)
      do_other_stuff (a)
    

is legal but suddenly becomes illegal when you turn it into

    
    
      let a = 1
      let b = pointer to a
      do_stuff(b)
      do_other_stuff (a)
      // ... etc etc
      do_more_stuff(b)
    

You add a legal statement down the function for a variable that's still valid
and in scope, and the calls above it go kablooey.

~~~
askyourmother
Agreed - not sure this is a good thing, making code and actions harder to
reason about. Another reason to reconsider Rust...

~~~
jerf
You do this exact thing all the time in non-Rust languages. Rust notices, and
then tells you about it. I don't think that makes code _harder_ to reason
about... I think that leans more in the "easier" direction.

I don't think you should dock Rust for pointing out bad practices that other
languages simply don't notice. I think you can dock it for complaining about
code that's really OK, which just happens to be exactly what they're trying to
fix here.

~~~
geofft
So, I don't endorse this reasoning, but I can see it. With Rust you have to
think about the possible failure cases of your code up-front and account for
them. In other languages, you don't have to.

For instance, I'd bet that most C or C++ apps in production that use
concurrency have some concurrency bug somewhere, that's so rare that nobody
has hit it yet (or the effect of the bug is minor). Those apps are running in
production and serving a valuable purpose. Rust would force you to solve the
edge case before deploying the app in production.

Occasionally, it's the right set of engineering tradeoffs to deploy something
that produces useful results 99.9% of the time and crashes .1% of the time.
(But, I guess you can say, you can always use Rust's 'unsafe' keyword to
acknowledge that something isn't quite right but you're deploying it anyway.)

~~~
kbenson
> Occasionally, it's the right set of engineering tradeoffs to deploy
> something that produces useful results 99.9% of the time and crashes .1% of
> the time.

Yes, but unfortunately that doesn't describe the situation we are usually
presented with. The developers most likely have not calculated that it runs
fine 99.9% of the time and has specific failure cases that account for 0.1% of
the time, they just don't know about the error. That is vastly different than
making an engineering tradeoff, since the people engineering it don't even
know there's a tradeoff being made, and thus can't make an informed decision
about it.

In some sense, rust actually enables the situation you are presenting, in that
it requires more explicit reasoning about behavior, and if you want to wrap a
chunk in unsafe after calculating that it should only negatively affect the
program operation 0.1% of the time, well then you actually are making a
tradeoff.

------
Joof
Is this coming out of Rust's intermediate stage before LLVM? The compiler
project seems to have gotten a lot more interesting :)

~~~
steveklabnik
MIR will make this much easier to implement, so we're blocking it on MIR, yes.

------
kinkdr
Personal opinion, but I would rather be given a way to explicitly define(or in
that case "undefined") the lifetime, rather than having the compiler trying to
be smart. I.e

let slice = ...

capitalize(slice);

"unlet" slice // <\- explicitly make it go out of scope

~~~
kinkdr
Or if you don't want to introduce a new keyword just use "let slice", which
shadows the first "slice", and hence making it go out of scope.

