<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 28, 2019, 10:01 PM  &lt;<a href="mailto:keld@keldix.com">keld@keldix.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Apr 28, 2019 at 11:04:58AM +0300, Henri Sivonen wrote:<br>
&gt; On Sat, Apr 27, 2019 at 2:15 PM Lyberta &lt;<a href="mailto:lyberta@lyberta.net" target="_blank">lyberta@lyberta.net</a>&gt; wrote:<br>
&gt; &gt; Where is SIMD is applicable?<br>
&gt; <br>
&gt; The most common use cases are skipping over ASCII in operations where<br>
&gt; ASCII is neutral and adding leading zeros or removing leading zeros<br>
&gt; when converting between different code unit widths. However, there are<br>
&gt; other operations, not all of them a priori obvious, that can benefit<br>
&gt; from SIMD. For example, I&#39;ve used SIMD to implement a check for<br>
&gt; whether text is guaranteed-left-to-right or potentially-bidirectional.<br>
&gt; <br>
&gt; &gt; Ranges are generalization of std::span. Since no major compiler<br>
&gt; &gt; implements them right now, nobody except authors of ranges is properly<br>
&gt; &gt; familiar with them.<br>
&gt; <br>
&gt; If a function takes a ContiguousRange and is called with two different<br>
&gt; concrete argument types in two places of the program, does the binary<br>
&gt; end up with one copy of the function or two copies? That is, do Ranges<br>
&gt; monomorphize per concrete type?<br>
&gt; <br>
&gt; &gt; For transcoding you don&#39;t need contiguous memory and<br>
&gt; &gt; with Ranges you can do transcoding straight from and to I/O using<br>
&gt; &gt; InputRange and OutputRange. Not sure how useful in practice, but why<br>
&gt; &gt; prohibiting it outright?<br>
&gt; <br>
&gt; For the use case I designed for, the converter wasn&#39;t allowed to pull<br>
&gt; from the input stream but instead the I/O subsystem hands the<br>
&gt; converter buffers and the event loop potentially spins between buffers<br>
&gt; arriving. At the very least it would be prudent to allow for designs<br>
&gt; where the conversion is suspended in such a way while the event loop<br>
&gt; spins. I don&#39;t know if this means anything for evaluating Ranges.<br>
&gt; <br>
&gt; &gt; From what I know only 8 bit, 16 bit and 32 bit byte systems actually<br>
&gt; &gt; support modern C++.<br>
&gt; <br>
&gt; Do systems with 16-bit or 32-bit bytes need to process text, or are<br>
&gt; they used for image/video/audio processing only?<br>
&gt; <br>
&gt; On Sat, Apr 27, 2019 at 3:01 PM Ville Voutilainen<br>
&gt; &lt;<a href="mailto:ville.voutilainen@gmail.com" target="_blank">ville.voutilainen@gmail.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On Sat, 27 Apr 2019 at 13:28, Henri Sivonen &lt;<a href="mailto:hsivonen@hsivonen.fi" target="_blank">hsivonen@hsivonen.fi</a>&gt; wrote:<br>
&gt; &gt; &gt; Having types that enforce Unicode validity can be very useful when the<br>
&gt; &gt; &gt; language has good mechanisms for encapsulating the enforcement and for<br>
&gt; &gt; &gt; clearly marking cases where for performance reasons the responsibility<br>
&gt; &gt; &gt; of upholding the invariance is transferred from the type<br>
&gt; &gt; &gt; implementation to the programmer. This kind of thing requires broad<br>
&gt; &gt; &gt; vision and buy-in from the standard library.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Considering that the committee has recently<br>
&gt; &gt; &gt;  * Added std::u8string without UTF-8 validity enforcement<br>
&gt; &gt; &gt;  * Added std::optional in such a form that the most ergonomic way of<br>
&gt; &gt; &gt; extracting the value, operator*(), is unchecked<br>
&gt; &gt; &gt;  * Added std::span in a form that, relative to gsl::span, removes<br>
&gt; &gt; &gt; safety checks from the most ergonomic way of indexing into the span,<br>
&gt; &gt; &gt; operator[]()<br>
&gt; &gt; &gt; what reason is there to believe that validity-enforcing Unicode types<br>
&gt; &gt; &gt; could make it through the committee?<br>
&gt; &gt;<br>
&gt; &gt; Both std::optional and std::span provide &#39;safe&#39; ways for extracting<br>
&gt; &gt; and indexing.<br>
&gt; &gt; The fact that the most-ergonomic way of performing those operations is<br>
&gt; &gt; zero-overhead<br>
&gt; &gt; rather than &#39;safe&#39; should be of no surprise to anyone.<br>
&gt; <br>
&gt; Indeed, I&#39;m saying that the pattern suggests that unchecked-by-default<br>
&gt; is what the committee consistently goes with, so I&#39;m not suggesting<br>
&gt; that anyone be surprised.<br>
&gt; <br>
&gt; &gt; The reason to<br>
&gt; &gt; &#39;believe&#39; that<br>
&gt; &gt; validity-enforcing Unicode types could make it through the committee depends<br>
&gt; &gt; on the rationale for such types, not on strawman arguments about<br>
&gt; &gt; things completely<br>
&gt; &gt; unrelated to the success of proposals for such types.<br>
&gt; <br>
&gt; The pattern of unchecked-byte-default suggests that it&#39;s unlikely that<br>
&gt; validity-enforcing Unicode types could gain pervasive buy-in<br>
&gt; throughout the standard library and that the unchecked types could<br>
&gt; fall out of use in practice. Having validity-enforcing Unicode types<br>
&gt; _in addition to_ unchecked Unicode types is considerably less valuable<br>
&gt; and possibly even anti-useful compared to only having<br>
&gt; validity-enforcing types or only having unchecked types.<br>
&gt; <br>
&gt; For example, consider some function taking a view of guaranteed-valid<br>
&gt; UTF-8 and what you have is std::u8string_view that you got from<br>
&gt; somewhere else. That situation does not compose well if you need to<br>
&gt; pass the possibly-invalid view to an API that takes a guaranteed-valid<br>
&gt; view. The value of guaranteed-valid views is lost if you end up doing<br>
&gt; validation in random places instead of UTF-8 validation having been<br>
&gt; consistently pushed to the I/O boundary such that everything inside<br>
&gt; the application uses guaranteed-valid views.<br>
&gt; <br>
&gt; (Being able to emit the error condition branch when iterating over<br>
&gt; UTF-8 by scalar value is not the only benefit of guaranteed-valid<br>
&gt; UTF-8 views. If you can assume UTF-8 to be valid, you can also use<br>
&gt; SIMD in ways that check for the presence of lead bytes in certain<br>
&gt; ranges without having to worry about invalid sequences fooling such<br>
&gt; checks. Either way, if you often end up validating the whole view<br>
&gt; immediately before performing such an operation, the validation<br>
&gt; operation followed by the optimized operation is probably less<br>
&gt; efficient than just performing a single-pass operation that can deal<br>
&gt; with invalid sequences.)<br>
&gt; <br>
&gt; On Sat, Apr 27, 2019 at 3:13 PM Tom Honermann &lt;<a href="mailto:tom@honermann.net" target="_blank">tom@honermann.net</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On 4/27/19 6:28 AM, Henri Sivonen wrote:<br>
&gt; &gt; &gt; I&#39;m happy to see that so far there has not been opposition to the core<br>
&gt; &gt; &gt; point on my write-up: Not adding new features for non-UTF execution<br>
&gt; &gt; &gt; encodings. With that, let&#39;s talk about the details.<br>
&gt; &gt;<br>
&gt; &gt; I see no need to take a strong stance against adding such new features.<br>
&gt; &gt; If there is consensus that a feature is useful (at least to some subset<br>
&gt; &gt; of users), implementors are not opposed,<br>
&gt; <br>
&gt; On the flip side are there implementors who have expressed interest in<br>
&gt; implementing _new_ text algorithms that are not in terms of Unicode?<br>
&gt; <br>
&gt; &gt; and the feature won&#39;t<br>
&gt; &gt; complicate further language evolution, then I see no reason to be<br>
&gt; &gt; opposed to it.<br>
&gt; <br>
&gt; Text_view as proposed complicates language evolution for the sake of<br>
&gt; non-Unicode numberings of abstract characters by making the &quot;character<br>
&gt; type&quot; abstract.<br>
&gt; <br>
&gt; &gt;There are, and will be for a long time to come, programs<br>
&gt; &gt; that do not require Unicode and that need to operate in non-Unicode<br>
&gt; &gt; environments.<br>
&gt; <br>
&gt; How seriously do such programs need _new_ text processing facilities<br>
&gt; from the standard library?<br>
&gt; <br>
&gt; On Sat, Apr 27, 2019 at 7:43 PM JeanHeyd Meneide<br>
&gt; &lt;<a href="mailto:phdofthehouse@gmail.com" target="_blank">phdofthehouse@gmail.com</a>&gt; wrote:<br>
&gt; &gt; By now, people who are using non-UTF encodings have already rolled their own libraries for it: they can continue to use those libraries. The standard need not promise arbitrary range-based to_lower/to_upper/casefold/etc. based on wchar_t and char_t: those are dead ends.<br>
&gt; <br>
&gt; Indeed.<br>
&gt; <br>
&gt; &gt; I am strongly opposed to ALL encodings taking std::byte as the code unit. This interface means that implementers must now be explicitly concerned with endianness for anything that uses code units wider than 8 bits and is a multiple of 2 (UTF16 and UTF32). We work with the natural width and endianness of the machine by using the natural char8_t, char16_t, and char32_t. If someone wants bytes in / bytes out, we should provide encoding-form wrappers that put it in Little Endian or Big Endian on explicit request:<br>
&gt; &gt;<br>
&gt; &gt;      encoding_form&lt;utf16, little_endian&gt; ef{}; // a wrapper that makes it so it works on a byte-by-byte basis, with the specified endianness<br>
&gt; <br>
&gt; I think it is a design error to try to accommodate UTF-16 or UTF-32 as<br>
&gt; Unicode Encoding Forms in the same API position as Unicode Encoding<br>
&gt; Schemes and other encodings. Converting to/from byte-oriented I/O or<br>
&gt; narrow execution encoding is a distinct concern from converting<br>
&gt; between Unicode Encoding Forms within the application. Notably, the<br>
&gt; latter operation is less likely to need streaming.<br>
&gt; <br>
&gt; Providing a conversion API for non-UTF wchar_t makes the distinction<br>
&gt; less clear, though. Again, that&#39;s the case of z/OS causing abstraction<br>
&gt; obfuscation for everyone else. :-(<br>
&gt; <br>
&gt; On Sat, Apr 27, 2019 at 2:59 PM &lt;<a href="mailto:keld@keldix.com" target="_blank">keld@keldix.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; well, I am much against leaving the principle of character set neutrality in c++,<br>
&gt; &gt; and I am working to enhance cheracter set features in a pan-character set way<br>
&gt; <br>
&gt; But why? Do you foresee a replacement for Unicode for which<br>
&gt; non-commitment to Unicode needs to be kept alive? What value is there<br>
&gt; from pretending, on principle, that Unicode didn&#39;t win with no<br>
&gt; realistic avenue for getting replaced--especially when other<br>
&gt; programming languages, major GUI toolkits, and the Web Platform have<br>
&gt; committed to the model where all text is conceptually (and<br>
&gt; implementation-wise internally) Unicode but may be interchanged in<br>
&gt; legacy _encodings_?<br>
<br>
 I believe there are a number of encodings in East Asia that there will still be<br>
developed for for quite some time.<br>
<br>
major languages and toolkits and operating systems are still character set independent.<br>
some people believe that unicode has not won</blockquote></div><div><br></div><div>Some people are wrong</div><div><br></div><div>    and some people are not happy with</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the unicode consortium. </blockquote></div><div><br></div><div>Some people will never be happy. Yet it is incredibly unlikely that someone would come up with a set of characters which is a strict superset of what is offered by Unicode, and nothing short of that would make it suitable to handle text.</div><div><br></div><div>Operating systems that are encoding independent are mostly a myth at this point. Probably always were. Linux is mostly utf-8, Osx is Unicode, windows is slowly getting there etc.</div><div><br></div><div>All of that is driven by marker forces. Users don&#39;t tolerate mojibake and the _only_ way to avoid that is to use Unicode.</div><div><br></div><div>This means in no way that c++ wouldn&#39;t be able to transcode inputs from all kind of encoding at i/o boundary.</div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">why abandon a model that still delivers for all?</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
keld<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>