Tracking issue for overloaded += operators (RFC 953) (feature augmented_assignments)

[nikomatsakis]

Tracking issue for RFC rust-lang/rfcs#953, which implements support for += operators.

cc @japaric

[nikomatsakis]

Rather bitrotted PR available here: #23171

[japaric]

Rather bitrotted PR available here: #23171

I'm working on a rebase of that PR

[solson]

It appears the implementation was merged in #28345 (but it's still unstable for now).

[vojtechkral]

Hi. What are the requirements to stabilize this feature?

[alexcrichton]

🔔 This issue is now entering its cycle final comment period to be stabilization in 1.8 🔔

Or at least the libs team is willing to stabilize the trait signatures. I believe the lang team is also thinking of having this in FCP for the 1.8 cycle as well (cc @rust-lang/lang)

[aturon]

The lang team approves final comment period for the entire feature.

[bluss]

This is a wanted feature in numerical crates of course.

There is one limitation of the current implementation that's appeared in ndarray, and it ties in with something else: There are no custom DSTs in rust. So when we produce an array view (slice of part of an array), we return a new struct type, for example ArrayViewMut<'a, f32>.

The += limitation is that it does not apply on rvalues, so the following does not compile:

//  Increment elements in row `i` by 1.0
array.row_mut(i) += 1.0;
// scale the 4 x 4 top left quadrant by alpha
array.slice_mut(s![..4, ..4]) *= alpha; 

Lifting this restriction doesn't need changing the method signatures.

[nikomatsakis]

On Sun, Feb 14, 2016 at 01:19:19AM -0800, bluss wrote:

The += limitation is that it does not apply on rvalues, so the following does not compile:

//  Increment elements in row `i` by 1.0
array.row_mut(i) += 1.0;
// scale the 4 x 4 top left quadrant by alpha
array.slice_mut(s![..4, ..4]) *= alpha; 

Lifting this restriction doesn't need changing the method signatures.

Interesting. I'm happy to see you overloading call notation to get
rvalues like that -- I've been thinking of this as an appealing
alternative to IndexMove (since it preserves the "[] is an lvalue"
concept).

[bluss]

I realized that the lvalue restriction makes sense. Without it, expressions like string.len() += 1 would compile too, and that's too confusing to allow.

[alexcrichton]

The libs team discussed this during triage yesterday and this has our stamp of approval. Gonna wait for the lang team to also weigh in on the FCP before stabilizing, however.

[aturon]

The lang team has likewise decided to stabilize this feature.