RFC: extension trait conventions

[aturon]

This is a conventions RFC establishing a definition and naming
convention for extension traits: FooExt.

Rendered

[Gankra]

Should we be conflating all the different kinds of extension here? There's extension traits for:

• supporting object-safety
• "special cases" of a base type (this one was distinguished in the proposal)
• implementing methods on "special" types like int or [T]
• extending a type someone else defined (similar to the previous)
• arguably the operator traits are a kind of extension trait, as it doesn't seem reasonable to generically accept anything that just impl's Index or whatever.

Obviously, these lines are a bit blurry.

Overall I like the recommendation (distinguish traits for generic programming from other traits with a simple suffix), I just want to be sure we aren't conflating unrelated concepts.

[aturon]

@gankro Thanks for the feedback! Here are some thoughts broken down by your categories:

• "special cases" of a base type (this one was distinguished in the proposal)

Eventually, this will be handled by where clauses at the method level, which will no longer require breaking things out into extra crates. It's not clear whether this will happen before 1.0, though, so we may have to freeze some extension traits as more granular than we'd otherwise like.

• implementing methods on "special" types like int or [T]

I've long wished we could do this another way, but there hasn't been a strong enough justification for the work, yet.

That said, there's a separate -Prelude suffixed for prelude extension traits. (Since they're in the prelude and not meant for generic programming, picking a long and very marked name like that is OK.)

• supporting object-safety
• extending a type someone else defined

These two are very closely related, since in general the blanket impl you provide when breaking out an object safe trait is actually adding methods to types defined elsewhere.

• arguably the operator traits are a kind of extension trait, as it doesn't seem reasonable to generically accept anything that just impl's Index or whatever.

I've sometimes thought the same thing, but actually many of these traits do end up used for generic programming (for better or worse).

The other thing is, these operator traits are "generic" in the sense that they apply to a large (unbounded) number of new types, whereas most extension traits are designed to apply to a single, or small family, of known types. So the "generic" aspect doesn't just mean generics in the technical sense, but also in a more fuzzy design sense.

In short, I think having just the Prelude and Ext suffixes should cover our needs, but I'd love to hear concrete alternatives if people have other ideas!

[liigo]

FooExtension maybe another alternative.

[alexcrichton]

Discussion

Tracking

[Thiez]

People are running into problems because the extension traits tend to have a blanket implementation (e.g. here, impl<A, I> IteratorExt<A> for I where I: Iterator<A> {}) which prevents overriding methods when a better implementation is possible. Perhaps the extension traits should never have a blanket implemention?

It is easy to come up with better implementations that the default, for example last() on a DoubleEndedIterator would be next_back(). Calling skip(100) on a RandomAccessIterator should not call next() a hundred times.

[Thiez]

When we get opt-out traits (#19) it might be possible to define something like IteratorExtDefault and then impl<A, I> IteratorExt<A> for I where I: IteratorExtDefault + Iterator<A> {}. Specific iterators can then opt-out of IteratorExtDefault and implement IteratorExt manually. But perhaps that's not worth the extra mess and we should simply never have blanket implementations for Ext traits at all.

[skade]

I see the problem that IteratorExt (and FooExt traits in general) are basically utils junkdrawers for Iterator with many useful default implementations. Reimplementing the whole thing just for having one method replaced seems a bit excessive, especially as those things tend to grow and not shrink. It squats a whole namespace.