But it is kind of a leak of abstraction. You don't have a way to control were the buffer is left. Am i missig something?

If some sort of seek is supported doing the math with the buffer, even if the underlying io is forward only i would +1 this.

readed buffer always here, it is in_buffer, with rewind_buffer @in_buffer_rem just pointing on it head again.
may be if we can set buffer size, would be nice, also

or may be better even rewind to requested size. for example read 3 bytes, and shift 3 bytes back

@kostya Can you provide some real code where you'd use this? I find it confusing too. What if you want to peek 3 bytes but the first byte is the last one in the buffer? You'll re-fill the buffer but then you won't be able to rewind.

In any case, it would maybe be useful to peek the IO::Buffered's buffer for some optimizations. For example when we parse a CSV from an IO we need to read char by char until we find a comma. Meanwhile we need to put these chars in a MemoryIO and when we find a comma we build a string out of it. If we knew the IO is buffered we could search the comma in the IO's buffer, and if it's there we could get a string right out from the buffer, without needing to append chars to an intermediate buffer. This is why parsing JSON/CSV from a String is usually much faster than parsing it from an IO. Though we'd have to think how to provide this optimization for all IOs that buffer data (currently IO::Buffered and MemoryIO)

if you request return 3 bytes, but buffer switched, should be exception. Btw, this is only for manual usage, when you known what you do, what the buffer size, and where you position in parsing.

this is actually enough for me:

module IO::Buffered
  def rewind_buffer(size : Int32)
    new_buf = @in_buffer_rem.to_unsafe - size
    new_size = @in_buffer_rem.size + size
    if new_buf >= in_buffer
      @in_buffer_rem = Slice.new(new_buf, new_size)
    else
      raise "invalid shift"
    end
  end
end