You can create an empty io-reader with std::io::empty(), which returns an std::io::Empty. That Empty doesn't implement the Seek trait. However, I don't see any reason why it shouldn't.
I don't understand how a reader which is always at EOF should be seekable. Can you please explain more about it?
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having Seek implemented for Empty. It allows it to be passed to more generic code.
@oberien Did you hit a case where you actually wanted to do this?
In https://github.com/algesten/ureq/issues/187 ureq is discussing ways to implement a 307/308 HTTP redirect. Those two codes (in contrast to 301/302/303) require the payload to be sent after the redirect. However, parts of the payload may already have been sent to the server, before the server responds with the redirect. With a generic API taking an impl Read as Payload, it's not possible to seek back to the beginning. Thus, one suggestion is to use impl Read + Seek instead. To allow an empty body (e.g. for a GET request), it would be nice to keep using io::Empty.
While ureq will probably decide to follow a different way for those redirects, I still think this pattern makes sense to support.
Most helpful comment
You can think of a reader which is always at EOF as a reader which is always at position 0 with a stream end of position 0. I don't think there is any disadvantage of having
Seekimplemented forEmpty. It allows it to be passed to more generic code.