Default the associated return type of unop/binop traits to `Self`

[japaric]

Because that's the common case and it's an ergonomic win. For example:

trait Add<RHS=Self> {
   type Result = Self;  // <-- default type

    fn add(self, RHS) -> Self::Result;
}

Would let us write trait Int: Add + Sub + ... instead of trait Int: Add<Result=Self> + Sub<Result=Self> + ....

This has to wait until default type parameters is implemented for associated types (#19476).

cc @aturon / @nikomatsakis

[bluss]

I don't see how Int: Add puts any restriction on Add::Result, regardless if there is a default value for the assoc type or not.

[Stebalien]

Now blocking on #29661 (stabilization of default associated types).

[dtolnay]

I agree with @bluss -- I don't see how T: Add would be equivalent to T: Add<Result = T> even if there is a default for the Result associated type. Default associated types as tracked in #29661 allow the associated type to be omitted from an impl of the trait, but does not affect what T: Add means.

trait Add<RHS = Self> {
    type Output;
    fn add(self, RHS) -> Self::Output;
}

struct S;
impl Add for S {
    type Output = ();
    fn add(self, _: S) -> () { unimplemented!() }
}

fn main() {
    fn f<T: Add>() {}
    f::<S>();
}

This compiles on stable Rust today and the function f accepts any type T that implements Add. It would be a breaking change for fn f<T: Add> to change to mean fn f<T: Add<Result = T>> when a default is added.

I agree that the current incantation of Add<Result = Self> + Sub<Result = Self> + ... could be handled better. I would be interested in seeing that explored in an RFC.