Non-Lexical Lifetimes Based on Liveness in Rust (smallcultfollowing.com)

  let a = 1
  begin block scope {
    let b = pointer to a
    do_stuff(b)
  } // end block scope and b is dead
  do_other_stuff (a)

Contrast:

  let a = 1
  begin block scope {
    let b = pointer to a
    do_stuff(b)
  } // end block scope and b is dead
  do_other_stuff (a)
  // ... etc etc
  do_more_stuff(b) // is obviously broken, b is not in scope

  let a = 1
  begin block scope {
    let b = pointer to a
    do_stuff(b)
    do_other_stuff (a) // is obviously broken, b is not dead
    // ... etc etc
    do_more_stuff(b)
  } // end block scope way down here

I suppose it will mean a programmer might have to think a little harder if they want to manually preempt compilation errors, but fortunately the compiler is there to catch them if they don't get it right. The example the OP points out is a situation that will likely play out like the following in most circumstances:

- programmer adds new use of variable b.

- compiler points out an existing use of some other value a that could invalidate b, and, importantly, highlights all the moving parts (conflicting use of a, use of b that prolongs its lifetime, etc.) in the error message.

- programmer edits code to avoid the problem.

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.