<div dir="ltr"><div><div><div><div><div><div><div><div><div>Dear Lyberta,<br><br></div>     Apologies for the delay. I think the point I&#39;m trying to make is that your stream type should not include the state at all. Perhaps, I should back up a bit:<br><br></div>     - The serializer type you have can include whatever it wants to perform the serialization (including (or not!) locale or whatever other state is necessary)<br></div>     - The <i><b>stream</b></i> type must not -- MUST not -- include anything about serialization or text or whatever.<br><br></div>     The only operations the stream type has is &quot;std::io::read( stream, buffer, length )&quot; and &quot;std::io::write( stream, bytes, length )&quot;. 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.)<br><br></div>     From there, you stack on what you need on the serializer type. As an example:<br><br></div>     std::io::stream s( ... );<br></div>     std::cool_serializer 
user_interactable( s, whatever, you, want );<br><br></div>     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&#39;s only job is to ask things that get serialized:<br><br></div>     int variable = ...;<br><div>
     
user_interactable.write(variable);<br><div>


    
int variable = user_interactable.read&lt;int&gt;();</div><div>     std::text variable2 = user_interactable.read&lt;std::text&gt;();</div>

<div><div><div><div><div>     <br></div><div>     You can add custom operators to the thing that&#39;s meant to be user_interactable: the stream. You can add encoding information. Customization points. Locales (or not). Anything your heart desires. It calls std::io::write(_my_s, my_serialized_int_bytes, length ); and std::io::read( buffer, maximum_lengths ); before passing the read bytes to serializer_customization_point&lt;std::text&gt;( buffer, read_length ); underneath (as an example). Now, concerns are separated: the IO stream is good at doing IO. And the serializer stream is good at serializing. Well-separated. Easy to optimize. You can even do things like pass the memory mapped data directly to the serializer&#39;s customization point, if that&#39;s the goal. But whatever you do...<br><br></div><div>     Keep the stream clean. Keep it transparent, make it safe to use, do not put state in it.<br><br>     Do not muddy its waters.<br><br></div><div>Sincerely,<br></div><div>JeanHeyd Meneide<br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 7, 2019 at 2:59 PM Lyberta &lt;<a href="mailto:lyberta@lyberta.net">lyberta@lyberta.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;      There should be no &quot;text IO&quot;. Binding attributes on stream objects to<br>
&gt; &quot;handle text&quot; is the mistake IO streams made; it absolutely muddled the<br>
&gt; concerns of IO streams and turned them into stateful messes on the same<br>
&gt; level of floating point and having to save / restore FP registers after<br>
&gt; each call or specific use in order to not break everything downstream /<br>
&gt; used after you made a few calls with specific &quot;sticky&quot; flags.<br>
<br>
So do you want to pass the state explicitly such as<br>
<br>
std::io::read(stream, state, variable);<br>
<br>
My idea is a bit of compromise that I put everything in a single object<br>
and provide a simple accessor function to change it such as<br>
<br>
auto my_state = stream.state();<br>
// ...<br>
// Change state<br>
// ...<br>
stream.state() = my_state;<br>
<br>
That way we still have the convenient syntax of<br>
<br>
std::io::read(stream, variable);<br>
<br>
&gt;      If you want IO in your text library, make it a single, atomic call<br>
&gt; where all the information required to serialize the text properly is done<br>
&gt; in a single function.<br>
<br>
I&#39;m totally fine with this design but I wonder if anyone actually has a<br>
use case where they can&#39;t just parse all the text into string at once.<br>
But I&#39;m fine with skipping this use case for now.<br>
<br>
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div>