We should eventually add default type parameters to all the operator traits

[benh]

trait Add<RHS,Result> { ... }
trait Sub<RHS,Result> { ... }
trait Mul<RHS,Result> { ... }
trait Div<RHS,Result> { ... }
trait Rem<RHS,Result> { ... }
trait Neg<Result> { ... }
trait Not<Result> { ... }
trait BitAnd<RHS,Result> { ... }
trait BitOr<RHS,Result> { ... }
trait BitXor<RHS,Result> { ... }
trait Shl<RHS,Result> { ... }
trait Shr<RHS,Result> { ... }

All the type parameters here could get a = Self so that the common case is way less noisy to implement for types that are themselves parameterized.

Example from that reddit post:

impl<T: Add<T, T>> Add<Vec2<T>, Vec2<T>> for Vec2<T> { ... }

becomes

impl<T: Add> Add for Vec2<T> { ... }

I guess this can happen whenever since it’s backwards compatible, like default type parameters in general, though maybe we’re gonna come up with something better with where clauses and/or associated types by then.

[cmr]

Seems reasonable, until you realize that any implementation that involves substituting the Result is going to require the default-parameters feature gate, and I’m not certain that we are going to keep them… I don’t want to use them for such core traits yet.

[bluss]

Unsure if this question is too tangential, but is Eq<T = Self> a viable way to get rid of Equiv<T>?

[dobkeratops]

" and I’m not certain that we are going to keep them…"

yikes… I hope they stay. they’re extremely useful. ( e.g., i could roll my own Vec<T,Index=i32> … parameterised index would let me get typesafe indices, also if Rust’s collection did Vec<T,Index=uint> , I’d be saved from rolling my own)

whats the argument against them?

[huon]

Equiv has the (unspoken) assumption that equiv objects have the same hash (or else HashMap.find_equiv wouldn’t work). It seems semireasonable for this assumption to move to a generic Eq, but it would mean that the A == B would only be “valid” to implement for A & B with the same hash, which may be conflating concerns.

[benh]

Yeah, if you’re gonna remove default type params then this obviously is moot. But if we end up un-featuregating them, we might want to keep this in mind~

[cmr]

whats the argument against them?

I don’t think there’s any specific arguments against them, I just have a vague concern about how it will mesh with other language features. I agree they are super useful – trying to keep them should be a goal.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.