The semantics are very straightforward: `?` will return as per the `return` keyword. So if you use it in a lambda, it will return from just the lambda, like returns in lambdas always do (Rust hasn't hewed to Tennent's Correspondence Principle for a long time now :P ).

  >  Does it bail out of just the lambda

Yes.

  >  What about nested functions?

It returns from the nested function, not the outer function.

  > a named nested function which can access its outer scope?

No, functions don't close over any scopes.

That's good. Now there's a clean way to handle errors in a block-structured fashion.

What you describe as "a match around a lambda" is the `catch` expression, which will catch `?`s thrown within it and allow you to match over them. This syntax has gone through RFC but its not implemented yet.

Of course for now you can create this control flow with `match (|| { block }) { }` as you describe.

It bails out of the lamda - https://is.gd/0TT8pr

Lamdas can capture their scope, and you can give them a name, so that might be useful? You can't use named functions (as per fn foo).

The answer seems obvious; it's the same behavior "return" has, i.e. it returns from the function it's currently in, not something a few levels up.

It might seem obvious, but Ruby, for example:

  def lambda_test
    lam = lambda { return }
    lam.call
    puts "Hello world"
  end

This will print "hello world". But this:

  def proc_test
    proc = Proc.new { return }
    proc.call
    puts "Hello world"
  end

Will print nothing, as the 'return' returns from proc_test. Examples taken from here: http://awaxman11.github.io/blog/2013/08/05/what-is-the-diffe...

Wow, that's a pretty nonsensical semantic. Thankfully, Rust is fairly sensible.

It makes more sense in-context; I did Ruby for years and never had to think about this once.

It gets used most to enable returning from the outer function while within loop-body-like procs. Rust iterators used to be like that too (pre-1.0), but they switched to the current style to get rid of that complexity.