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_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode