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.
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.
" 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)
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.
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~
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.