On Sat, 31 Aug 2019 at 23:06, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> >> If you presented a modified C compiler with reasonably designed built-in
> >> string object to the current C committee, I think you'd have a very high
> >> chance of success. Everybody recognises that strings need doing right,
> >> and a native built-in object is widely seen as the correct approach.
> >
> > Can you provide more info? Why a sequence of unsigned integers suddenly
> > need a built-in type?
>
> It's a personal summation of where the committee are at of course, but I
> would say:
>
> 1. VLAs are generally recognised as having failed, and everybody hates
> non constant sizeof().
>
> 2. Zero terminated char arrays are universally recognised as not fit for
> purpose.
>
> 3. All previous attempts to improve string handling without touching the
> core language have not been successful.
>
> 4. C generics and macros aren't powerful enough.
>
> 5. There is a general wish that being able to efficiently treat a bunch
> of bytes simultaneously as either UTF-8 characters or their raw bytes,
> and switch between interpretations at any time, would be highly desirable.
>
> 6. There would be a hope that some form of static lifetime checking
> would be possible. Some speak of Rust style annotation in the same
> breath, but that's a minority opinion. Still, something better than
> nothing would be very interesting.
>


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)
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
to add (pointer size) functions everywhere - it's a lot of functions




>
> Niall
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>