<div dir="ltr"><div>Thank you for the feedback. I&#39;ll try to address the points one at a time.</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In std::text::encoding_errc it says:<br>
<br>
// sequence can be encoded but resulting<br>
// code point is invalid (e.g., encodes a lone surrogate)<br>
invalid_output = 0x05<br>
<br>
No, lone surrogates are fully valid code points, but they are invalid<br>
scalar values.<br></blockquote><div><br></div><div>I can clarify the comment. The goal is that invalid_output describes things that can&#39;t end up in the sequence as far as the encoding can tell. For example, valid UTF16 will not produce a lone surrogate code point in the sequence. So I should say &quot;... but resulting code point is invalid for the encoding&quot;.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don&#39;t think converting to scalar values is &quot;decoding&quot;, especially if<br>
the code uses dumb string types.<br></blockquote><div><br></div><div>That&#39;s probably closer to a matter of perspective. If your code points are already all scalar values, then it&#39;s a no-op. Otherwise, it&#39;s decoding -- just a very light one.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In 3.2.2.3 it talks about assuming that text is valid, this can be<br>
enforced by strong types such as scalar_value_sequence.<br></blockquote><div><br></div><div>You need a way to get to `scalar_value_sequence` to begin with. scalar_value_sequence can be the result of a text_encode or text_decode operation. And, this encoding scheme does not prevent someone from using either char32_t as their code point type or unicode_scalar_value as their code point type, or having scalar_value_sequence as the &quot;OutputRange&quot; for the encode or decode operations.<br><br></div><div>Regardless, you will still have &quot;char*&quot;, &quot;char8_t*&quot;, &quot;char16_t*&quot; and similar that may or may not be a sequence of scalar values. assume_valid_handler lets someone &quot;bless&quot; their storage, saying &quot;yes, it&#39;s already scalar values, I checked and its fine&quot;.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In 3.2.3 using char32_t directly may be a bad idea. I think we should<br>
focus on strong types instead... Oh, it doesn&#39;t require Unicode...<br></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If it provides ASCII it then better provide ASCII character type. We<br>
don&#39;t want to continue abusing &quot;char&quot;.<br></blockquote><div><br></div><div>I have not written out sketches of what these encoding types will loo at, as you&#39;ve noticed. This is because Tom Honermann and others have expressed great interest in pursuing what was done with text_view, where each encoding has its own associated input and output types. The question of signaling compatibility was up in the air, with ideas and basic implementation to date suggestion we check for (implicit) convertibility between the Encoder&#39;s character type and the Decoder&#39;s Character Type (e.g., they can both interoperate with each other using a unicode_scalar_value conversion).<br><br></div><div>Others have expressed great concerns for such a system (e.g., Henri Sivonen&#39;s post and the resulting discussion). I am not sure there is a clear winner here: being r0 of this proposal and since I might make this a school project, I would like to do work in the space and report back field experience rather than go all-in on a design that results in a bad slip-ups from mixing character sets, or bad conversion headaches for users.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don&#39;t like basic_utf8 providing encode_lone_surrogates parameter.<br>
That&#39;s not UTF8 then at all.<br></blockquote><div><br></div><div>As stated, &quot;this is not going to 
be looked into too deeply for the first iteration of this proposal.&quot; That is, I am not going to actively pursue such a path, it&#39;s just for thinking about. Whether or not we need these modes or if it just isn&#39;t worth implementer time is completely fine. I&#39;m not bothered about not having this and throwing it out of R1/R2 of the proposal, because Encoding is already concept-ified and can be swapped in and out at will. If someone really wants WTF8, they can write their own WTF8. It will be a small waste of their time having to reimplement _mostly_ what&#39;s inside the standard&#39;s encoding, but oh well: they&#39;ll survive.<br></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For scalar value and grapheme cluster containers we would need iterator<br>
or range functions. My code uses next_scalar_value and<br>
previous_scalar_value so I can iterate scalar values inside the code<br>
unit range.<br></blockquote><div><br></div><div>I haven&#39;t gotten that far yet. :D<br><br></div><div>Seriously, after encoding facilities, normalization needs to be addressed. It&#39;s incredibly important because some APIs (like MS&#39;s WideCharToMultiByte and MultiByteToWideChar) perform normalization *for* you, if you ask it. There are performance gains to be had for the free functions I plan to write if we let an implementation both transcode and normalize at the same time.
***

<br><br></div><div>
*** - needs to be proven out with benchmarks, first<br></div><div><br></div><div>Again, thank you for the feedback. I&#39;ll do my best to clean up what I can soon.<br></div><div><br></div><div>Sincerely,<br></div><div>JeanHeyd<br></div></div></div>