Forwarding Peter's email to SG16 since it's relevant to today's discussion
and contains the list of options that we have.

- Victor

---------- Forwarded message ---------
From: Peter Dimov via Lib <lib_at_[hidden]>
Date: Tue, May 7, 2024 at 12:12 PM
Subject: Re: [isocpp-lib] Issue 4087: Standard exception messages have
unspecified encoding
To: Tom Honermann <tom_at_[hidden]>, <lib_at_[hidden]>
Cc: Peter Dimov <pdimov_at_[hidden]>


Tom Honermann wrote:
> On 5/7/24 12:54 PM, Peter Dimov via Lib wrote:
> > Tom Honermann wrote:
> >> I don't think the proposed resolution is implementable since the
> >> ordinary literal encoding is not necessarily known at run-time and
> >> there is no way for it to be provided from a call site (at least, not
> >> without plumbing an additional parameter with a default argument to
> >> everywhere that might throw a filesystem_error object).
> > The literal encoding is a constant, so there's no need for it to be
> > passed as a parameter.
>
> In the standard, yes, but less so in the real world where it can vary
from one
> TU to another (and does in practice).

I don't think this is a scenario we need to concern ourselves with; but even
if we hypothetically did, passing a parameter to the throw point is not
going
to fix things.

That's because it's what() that needs to return the literal encoding of the
translation unit calling it, not the throw point (which doesn't know who
will
call what().)

In practice, the implementation will transcode to the literal encoding in
the constructor of filesystem_error. There's nothing better to do.

Also in practice, we have the following options:

1. Return a mishmash of encodings from exception::what;
2. Return a string in the literal encoding from exception::what;
3. Return a string in UTF-8 from exception::what;
4. Return a string in "the runtime locale encoding" from exception::what.

(4) is in quotes because there's no "the" runtime locale encoding.

(3) is what everyone needs and wants, but it's a breaking change.

(1) is what happens today, but we don't want it.

(2) is the only option we can realistically adopt, and in practice, most of
the time, that's what we get today, in whole or in part.


_______________________________________________
Lib mailing list
Lib_at_[hidden]
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib
Link to this post: http://lists.isocpp.org/lib/2024/05/28203.php