RFC: remove blanket ext implementations

[skade]

Rendered

Previous discussions:
rust-lang/rust#19435 (comment)
#445 (comment)
/~https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-11-25.md#extension-traits

Considering that I cannot get a good answer on how to work around issues with the new system, I think this is worth revisiting.

http://stackoverflow.com/questions/27267767/working-around-the-limitations-of-extension-traits

[Thiez]

A (rather unsurprising) +1 from me.

[aturon]

@skade

I'm sorry for taking so long to get back to you on this RFC; I've gotten quite behind.

While I think the concern here is legitimate for sure, I agree with the comments @thestinger made in your links above: the right way to solve this problem, in general, is through "specialization". That is, we clearly need a way to provide blanket implementations that can also be overridden for more specific types. This is a frequently requested feature, and I suspect it will be investigated soon after 1.0.

On the other hand, the downside of your proposal here is not too serious, since the extra impl is easy to write, and if you forget it, you will quickly be reminded when you try to use your iterator. Moreover, even if you've published an API without the IteratorExt impl, it can always be added backwards-compatibly.

So, this is a balance between locking into a solution that's better short-term (as proposed here) or long-term (banking on specialization). Given that specialization is almost certain to happen, I personally lean toward the long-term approach here.

[thestinger]

My proposal for handling the iterator optimizations can be done without any new language features. There's no need to have an ugly design with both duplicated implementations and absolutely no way of handling methods like skip that are implemented with adaptors. I don't think making these real default methods and overriding them makes any sense at all. It's strictly worse than designing it to handle optimizations for random-access iterators in general via a few extra base methods.

[aturon]

@thestinger Ah, sorry, I missed your second comment on the thread and assumed you were talking about specialization.

[skade]

@aturon I'd also like to note that the linked stackoverflow question has a solution in some cases: if the function is implemented on the struct, it will be preferred over the trait. This helps in this case at least, but doesn't help in generic code.

(updated with thiez comment below)

[Thiez]

@skade it wouldn't be preferred in generic code. For example:

fn count_iter<T: Iterator>(t: T) -> usize { t.count() }

#[derive(Copy)]
struct MyItr;
impl MyItr {
    fn count(self) -> usize { println!("MyItr.count was called!"); 0 }
}

impl Iterator for MyItr {
    type Item = bool;
    fn next(&mut self) -> Option<bool> { None }
}

fn main() {
    let it = MyItr;
    println!("{}",count_iter(vec![1,2,3,4].into_iter()));
    println!("{}",count_iter(it));
    println!("{}",it.count());
}

Will only print the silly message once, for the last statement.

[skade]

@Thiez Right. I didn't express that properly, updated the comment. Thank you!

[aturon]

FWIW, it's looking likely that we'll be able to merge back in IteratorExt regardless.

[Thiez]

Excellent, that should solve this issue nicely.

[aturon]

I'm going to go ahead and close this RFC for now; once the where Self: Sized treatment of object safety is in place, we plan to remove the extension trait here.