[SG16-Unicode] Replacement for codecvt
Niall Douglas
s_sourceforge at nedprod.com
Sat Aug 31 23:06:11 CEST 2019
>> 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.
Niall
More information about the Unicode
mailing list