JeanHeyd Meneide:
> Dear Lyberta,
>
> Apologies for the delay. I think the point I'm trying to make is that
> your stream type should not include the state at all.

Well, first, I think we should define what kind of state there is. The
essential state is the current position in the stream and possible error
state maybe. iostreams have these 4 bits of std::ios_base::iostate that
I still use in my library for now.

Another kind of state is format state that defined how IO should be
performed.

> The only operations the stream type has is "std::io::read( stream,
> buffer, length )" and "std::io::write( stream, bytes, length )".
Everything
> else on the stream object should be for the sole purpose of supporting
> those 2 operations, and literally nothing else. (Maybe async versions as
> well, etc.)

My design has raw read and write as member functions:

void read(std::span<std::byte> buffer);
void write(std::span<const std::byte> buffer);

std::io::read and std::io::write are customization points.

> Note the proper separation of concerns. Now, stream has one job and
> one job only: writing and reading bytes. The serializer can be made to
have
> all the customization points in the world, all the state it wants, and all
> the functionality, but now none of it gets in the way of whatever the
> stream object is supposed to be doing. The serializer's only job is to ask
> things that get serialized:

I agree that if we want to make a separate type for reading text more
akin to iostreams, it seems like a good idea. Not sure about other types.

I guess I'm gonna write a synopsis of my design so we can have a more
tangible discussion.