std: Bring back half of Add on String

[alexcrichton]

This adds an implementation of Add for String where the rhs is <S: Str>. The
other half of adding strings is where the lhs is <S: Str>, but coherence and
the libcore separation currently prevent that.

[alexcrichton]

This has been a highly requested feature since the move away from ~str. I agree that it is not performant, but the precedence is quite overwhelming.

[huonw]

Copying my comment from #14481 for posterity:

---

I'm not keen on the Add impl for string. It seems to easily encourage inefficient/overallocating code since it doesn't reuse the allocation of its argument, meaning s = s + a is horrible (especially in a loop). (And I relatively often see code approximately equivalent to that.)

I would be very interested in waiting a little longer to see if not having it is just too unbearable.

(Also this addition on strings isn't even commutative, i.e. it flies in the face of mathematical convention for the + operator. :P )

[huonw]

Travis failed btw.

[adrientetar]

I agree. This seems too much like Python.

[kud1ing]

I think people expect something like this (even when imperformant), since many other languages provide it: http://rosettacode.org/wiki/String_concatenation

[japaric]

How about we implement the AddAssign trait (when available) instead of the Add trait.

That way one can do s += a, that desugars to s.add_assign(&a), which is implemented as s.push_str(a.as_slice()) or s.push_char(a) depending on the type of a.

That way people can have some sugar, without us encouraging inefficient reallocations.

[bill-myers]

How about adding new versions of add that take parameters by value instead of by reference (for a total of 4 versions), and then having the compiler automatically pass by value when the value is no longer used?

The more general s = any_function(s + a) would then result in a call to a variant of add that takes the first parameter by value , which would of course be implemented by appending in place (if there is space).

One could also automatically rewrite s = s + a to s += a so that it works when s is an lvalue dereference of a &mut.

[lilyball]

@bill-myers That's rather magical behavior. Adding a later use of a variable should not silently change the semantics of earlier code. Note here that it's not just allocation semantics; the actual behavior could be subject to change as well, as this is just invoking user-defined code.

[huonw]

Theoretically we could actually just have Add take everything by-value and implement it like

impl<'a,'b> Add<&'b BigInt, BigInt> for &'a BigInt {
    fn add(self, other: &'b BigInt) -> BigInt { ... }
}

However, (with current-Rust) this would mean that a + b desugaring to just a.add(b) would require it to be called like &bigint + &bigint for types that take by reference (but all the primitives would be fine with by-value and so they would not require references).

[hatahet]

nit: return s; -> s :)