Implicit closure parameters

The current closure style is great. It's simple and to the point and leaves little to be desired.

However, I often find myself writing code like this:

some_operation().and_then(|x| x.get(1));

Where all I'm doing is call an accessor on a single argument.
Not having to introduce a single temporary variable for use in short expressions is nice and useful in the case of short in-line expressions.

A few programming languages provide a sort of syntactic sugaring to this pattern, of which I will mention two.

Scala Style

The Scala style of implicit closure parameters is simply to use an underscore.

some_operation().and_then(_.get(1));

Pros: The underscore is already used for other things in Rust, most notably generic types and patterns.

Cons:

• Yet another meaning for _.
• Looks unnatural when referencing and dereferencing: &_, &mut _, *_

Scala's style also lets you do this for closures that take multiple parameters:

vec.iter().fold(0, _ + _);

which would be the same as

vec.iter().fold(0, |acc, x| acc + x);

Granted, I feel this is somewhat less readable.

Kotlin Style

Kotlin uses a special variable called it

some_operation().and_then(it.get(1));

Pros:

• Doesn't use an underscore, and looks more like natural code.
• Can be used with the existing reference and dereference operators &it, &mut it, and *it don't look out of place

Cons:

• New users might be confused where the mysterious variable suddenly appeared from.
• The variable also doesn't have any other uses, so new special rules would have to be applied to this one specific case.

Unlike Scala, Kotlin only uses this to replace a single variable.

This is more of a quality-of-life request moreso than anything, though I still feel it's worth bringing to attention.

Personally I'm split between the two syntaxes, the succinctness of _ is great and quick to type, but it somehow feels like it makes more sense.

Start by reviewing the proposed Scala-style and Kotlin-style syntaxes and the existing comment discussion. Determine whether the request has a settled direction and what an accepted Rust RFC would need to specify; done means a resolved design rather than an implementation-only change.