> 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.

If he breaks the requisite parts out into a standalone git repo, I'll be
happy to submit issue requests to that.

In my opinion, every WG21 library proposal should come with a reference
implementation in a standalone, highly reusable, submodularisable git
repo. I know that I don't *quite* achieve that myself, but I think it
particularly important to avoid bundling reference implementation in
with lots of other unrelated stuff.

People won't lock in dependencies on bundles, too ripe for breaking
change. They like self contained, single purpose, orthogonal git repos.

> 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 ;)

Alas my plate is overflowing. I have four new papers in progress, such
is my overload that none of those four will make Belfast.

>> 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.

I gotta be blunt here, if text reencoding throws exceptions, it has the
wrong design.

>> 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.

I can give advice.

>> 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.

Unfortunately Ranges-based libraries would be a showstopper for me.

The problem is their current hefty impact on build times. Most of my
clients, and consumers of my libraries, therefore ban Ranges in their
codebases.

Even long term, I can see outright bans on Ranges in header files
continuing until compilers bake Ranges into the language. So expect a
substantial subset of C++ users refusing to use *any* Ranges based
library, including standard libraries, for at least a decade or more to
come.

Once again, being blunt here, I can't see why text reencoding needs
anything more than span<T> and basic_string_view<T>. Ranges
auto-understands both of those. Again, if the design really needs
Ranges, it has to be the wrong design.

Niall