<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 31 Aug 2019 at 23:06, Niall Douglas &lt;<a href="mailto:s_sourceforge@nedprod.com">s_sourceforge@nedprod.com</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;&gt; If you presented a modified C compiler with reasonably designed built-in<br>
&gt;&gt; string object to the current C committee, I think you&#39;d have a very high<br>
&gt;&gt; chance of success. Everybody recognises that strings need doing right,<br>
&gt;&gt; and a native built-in object is widely seen as the correct approach.<br>
&gt; <br>
&gt; Can you provide more info? Why a sequence of unsigned integers suddenly<br>
&gt; need a built-in type?<br>
<br>
It&#39;s a personal summation of where the committee are at of course, but I<br>
would say:<br>
<br>
1. VLAs are generally recognised as having failed, and everybody hates<br>
non constant sizeof().<br>
<br>
2. Zero terminated char arrays are universally recognised as not fit for<br>
purpose.<br>
<br>
3. All previous attempts to improve string handling without touching the<br>
core language have not been successful.<br>
<br>
4. C generics and macros aren&#39;t powerful enough.<br>
<br>
5. There is a general wish that being able to efficiently treat a bunch<br>
of bytes simultaneously as either UTF-8 characters or their raw bytes,<br>
and switch between interpretations at any time, would be highly desirable.<br>
<br>
6. There would be a hope that some form of static lifetime checking<br>
would be possible. Some speak of Rust style annotation in the same<br>
breath, but that&#39;s a minority opinion. Still, something better than<br>
nothing would be very interesting.<br></blockquote><div><br></div><div><br></div><div>I would say C is a non issue - we could, arguably just not care, and C++ has enough to deal with a sized string type ( even without changing existing literals, strlen is _for all intent and purposes_ constexpr in all implementations)</div><div>The real problem is system apis (both posix and win32 and all existing C code) - null termination in C++ exist for compatibility with that and it seems unlikely that we would manage to convince win32 or posix people</div><div>to add (pointer size) functions everywhere - it&#39;s a lot of functions</div><div><br></div><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">
<br>
Niall<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></div>