Seek needs finalization of its API

[alexcrichton]

There is currently an XXX on the seek trait asking a question about what to do about seeks out of bounds of the current file. Additionally, this leads to the fail!()-ing implementations of Seek on MemReader, BufReader, and BufWriter. MemWriter currently has an implementation that fills with 0s when you seek beyond the end and then perform a write.

In my opinion, the semantics should be defined as:

• If you seek to a negative offset, return an error immediately (from the call to seek).
• If you seek within "the file", we're all good
• If you seek beyond the end of "the file", then it's a valid operation and it's left up to the implementation to decide what to do afterwards. For example, a writer may decide to fill the intermediate gap with 0s. On the other hand, a reader would return an EndOfFile error on the next read (etc.).

This behavior follows what lseek + read + write appear to do. Regardless, we need to decide on this for 1.0. Nominating.

[alexcrichton]

Additionally, tell can fail right now, but it would be super awesome if it didn't have to. Do we actually prevent all of the error cases?

[pnkfelix]

Accepted for P-backcompat-libs

[emberian]

Someone in IRC also pointed out that seek/tell should be split into their own traits, with Seek probably inheriting from Tell. I don't remember the exact argument.