Sugar for closures with restricted access to enclosing's names.

If I am writing a long function, I often want to close off a chunk of code with { code_in_here } so that local variables I declare within the chunk don't "escape". Example:

fn long_function() {
   let mut x = 1;
   let y = 3
   {
      let y = 2;
      println!("I have {} apples");
   }
   assert!(y == 3);
}

However, inside the { }, it's still possible to read (and even write to) x. When reading long functions, I would like a way of assuring that a given complicated chunk of code only touches the variables I want it to touch.

A solution:

fn long_function() {
   let x = 1;
   let y = 3
   {fn t(x: &i32) { 
      let y = 5;
      println!("I have {} apple and {} oranges.", x, y);
   }t(&x);}
   assert!(y == 3);
}

This works, and does exactly what I need, but is rather ugly. I suggest a bit of built-in sugar for this use case. Perhaps rather than:

{fn t(args: &T, to: &mut U, pass: &V) { 
   //isolated logic
}t(&args, &mut to, &pass);}

we would have:

close (&args, &mut to, &pass) {
   // enclosed logic, assured not to touch anything but args, to and pass
}

And we can tell just by looking at one line exactly what variables this chunk of code touches and what its side effects are.

...or even better, a closure with controlled access to its enclosing scope that returns a value:

let a: i32 = close (&args, &mut to, &pass) -> i32 {
   // enclosed logic, assured not to touch anything but args, to and pass
   to = args + pass;
   let some_int = 5 - args;
   some_int
}

The issue does not name implementation files or tests; start by reviewing its closure-scope examples and the repository's RFC process. Compare the proposed syntax and alternatives, then define the semantics and determine whether the proposal is ready for an accepted RFC.