Add fn skip(n: uint) with a default implementation to Reader

[carllerche]

Reader should have an extra fn that allows skipping a number of bytes. The default implementation could look something like:

fn skip(n: uint) { let _ = self.read(Vec::from_elem(n, 0u8); }

However, BufReader could implement the fn by simply updating the internal cursor. This would allow more efficient skipping w/o having to require Seek.

[pongad]

This seems useful though reader does have a few methods on it already. I'm wondering what @alexcrichton thinks?
Edit: I'm not sure if this is a worthwhile change anymore. We can easily to reader.read_exact(n) to achieve the same thing.

[alexcrichton]

I'm worried about adding more methods to readers that downstream consumers need to consider to override. Having one flush() method is unfortunate, and I think time should be taken to consider whether this is justified to add it or not.

I don't think that we can quite use read_exact for this because in theory skip doesn't actually have to read any data. It does sound quite similar to seek though...

[nox]

Any news on this? I'm writing an IFF reader and I want users to be able to skip chunk bodies, requiring Seek for just this seems overkill.

[wycats]

The problem is that given today's (and likely future) coherence rules, you cannot create a trait that uses Seek if available but otherwise falls back to a less efficient Reader:

impl<T: Seek> PossiblyInefficientSeek for T {
    // ...
}

impl<T: Reader> PossiblyInefficientSeek for T {
    // ...
}

This is actually a decent motivating use-case for allowing an implementation of a trait to refine an existing implementation defined on a superset of types.

[wycats]

@pongad I do not think read_exact is appropriate, since it requires allocating a buffer of n size even if the backend supports efficient skipping.

[nikomatsakis]

@alexcrichton it is true that having too many random convenience methods can be a problem, but I think that it makes sense to add methods for operations that can be implemented much more efficiently in some contexts than others. In other words, while skip is technically implementable as a read, there is a big efficiency difference between a call to fseek and reading tons of bytes.

[steveklabnik]

@carllerche did this end up getting addressed in io reform?

[carllerche]

@steveklabnik Not yet. I think (hope) it is coming pre 1.0 though. cc @aturon

[aturon]

Nominating for 1.0-beta P-high. (Should be trivial.)

[pnkfelix]

P-high, I-needs-decision (not 1.0 beta blocker)

[alexcrichton]

In today's day and age this sort of addition (to a core trait like Read) will require an RFC, so I'm going to close this in favor of that course of action.