[SG16-Unicode] Feedback on p1629r0

Lyberta lyberta at lyberta.net
Sun Jun 23 18:58:00 CEST 2019


JeanHeyd Meneide:
>      I would greatly caution against Unicode IO, or <Anything> IO. IO must
> and always be dealing with std::byte: nothing more, nothing less.

Well, we can work in terms of code units instead of bytes and if we have
underlying stream to be byte stream, we get encoding schemes for free.

How would you parse, say, JSON without text streams?

>      You cannot mix I/O with encoding: you pull out std::byte and let the
> user copy, inspect, cast or verify the contents on their own.

I can pull 2 bytes from byte stream and automatically see if they form a
valid UTF-16 code unit. No need to ask user. Then I pull it into text
layer and see if I get a valid scalar value.

I'm trying to implement range concepts in my code so I get design for
scalar_value_sequence that I want to propose. Then I can build Unicode
streams on top of that.

> 
>      I would be more okay with a *Serialization* layer, separate from both
> Unicode and I/O. It would define a way to serialize most types, but allow
> the user to override that with their own application-specific defaults.

Well, there are 2 ways to serialize types: as bytes and as text. They
require 2 types of streams, obviously.

>      I think I/O should be left for the (potentially upcoming) IO Study
> Group:

Yes, I've recently contacted them to review my IO + serialization proposal:

https://github.com/experimental-io/experimental-io/issues/13



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://www.open-std.org/pipermail/unicode/attachments/20190623/3a19a155/attachment.bin 


More information about the Unicode mailing list