Lifetime constraints on e.g. ByteSlice::splitn_str are too restrictive

[glandium]

They prevent things like:

use bstr::ByteSlice;

pub trait SliceExt<C> {
    fn split2(&self, c: C) -> Option<(&Self, &Self)>;
}

impl SliceExt<&[u8]> for [u8] {
    fn split2(&self, b: &[u8]) -> Option<(&[u8], &[u8])> {
        let mut iter = self.splitn_str(2, b);
        match (iter.next(), iter.next()) {
            (Some(a), Some(b)) => Some((a, b)),
            _ => None,
        }
    }
}

impl SliceExt<String> for [u8] {
    fn split2(&self, b: String) -> Option<(&[u8], &[u8])> {
        let mut iter = self.splitn_str(2, &b);
        match (iter.next(), iter.next()) {
            (Some(a), Some(b)) => Some((a, b)),
            _ => None,
        }
    }
}

The splitter doesn't need to have the same lifetime as the the slice that is being split.

[BurntSushi]

Fixing this is a breaking change, so I'm putting this in the 1.0 milestone.

[glandium]

Out of educational interest, could you detail why that is so? Intuitively, that doesn't seem like so to me.

[BurntSushi]

Seems to me like it requires the iterator type to be parameterized over two lifetimes instead of the single one it has today. Adding a new non-default type parameter is a breaking change.

[glandium]

Oh, right. Makes sense. Maybe it would be worth returning an impl Iterator for 1.0?

[BurntSushi]

No. Because then how do you impl things like DoubleEndedIterator? Or FusedIterator? You'd have to get everything right up front. Returning impl Trait in public APIs isn't a good idea unless you need it for unnamed types.