[SG16-Unicode] Replacement for codecvt

Tom Honermann tom at honermann.net
Thu Aug 29 16:31:41 CEST 2019


On 8/29/19 8:51 AM, Niall Douglas wrote:
> On 29/08/2019 13:25, Tom Honermann wrote:
>> Hi, Niall. See JeanHeyd’s http://wg21.link/p1629. This is the direction
>> SG16 is currently heading for encoding conversion functions.
> Yes, this API looks *much* better. Thanks for the reminder.
>
>> JeanHeyd has an implementation available and it would be great to get
>> feedback on how well it works for you!
> Best I can find is
> https://github.com/ThePhD/phd/tree/master/include/phd/text
Yes, that is the right repository.
>
> I'm happy to trial a third party library and test out the proposed API,
> but I would have requirements due to the existing user base of LLFIO:

Two requests then:

1) Submit pull requests to JeanHeyd for features that you need. His 
target is C++23 of course and I at least don't want to see him get 
distracted with supporting earlier standards.  If we need that to 
evaluate the design, so be it, but please try and assist where 
possible.  I see this work as SG16's #1 priority for C++23.

2) Write papers proposing changes to the interface that you would need 
(e.g., deterministic exceptions).  Papers will help us more quickly 
evaluate and consider changes.  Any such papers should include 
motivation, examples, and proposed changes (preferably wording if 
applicable as well).  But you know all that of course ;)

>
> 1. C++ 14
>
> 2. Works correctly on Windows and VS2019.
These seem like areas that you or others could help out with.
>
> 3. Anywhere where you might throw an exception, you need to use a
> deterministic alternative like error_code, Outcome, etc.
I think this needs a paper.
>
> 4. Self contained single purpose repo suitable for git submoduling OR
> single include file.
I agree this would be helpful for encouraging experimentation and 
feedback.  JeanHeyd, any thoughts on this?
>
> 5. cmake build system suitable for reuse from a cmake superproject (i.e.
> targets only modern cmake, exports the targets consumed by the superproject)
This seems like something that you or others could help out with.
>
> 6. Any public headers should not include anything "heavy" like Ranges,
> Variant etc as some of my user base like to include LLFIO headers in
> global headers. String is acceptable, as LLFIO includes <filesystem>.

This library is fundamentally ranges based.  I don't see any way to 
avoid dependencies on ranges in the interface; that is something we 
explicitly desire.

Tom.

>
> Niall
> _______________________________________________
> SG16 Unicode mailing list
> Unicode at isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/unicode




More information about the Unicode mailing list