Ah, right. Hana pointed out on Mattermost that the std:: exceptions
use char const *, not std::string. This does not change my point,
which is that they do not use char8_t.

Zach

On Mon, Jan 13, 2025 at 10:07 AM Zach Laine
<whatwasthataddress_at_[hidden]> wrote:
>
> I mentioned this to Barry privately, but I think that string_view is
> the more consistent option. All the existing exceptions in the
> language use std::string as the return type of what(). I see no need
> to change that here. You get whatever encoding the implementation
> produces, for all what() implementations, for this and all other
> exceptions.
>
> std::string_view and std::u8string_view have the same invariants with
> regard to encoding (that is, no invariants at all). The only reason
> to use u8 that makes any sense to me is alongside a non-u8 version, to
> advertise semantics to the user via difference in type. Since we
> cannot do that here, no u8 seems right to me.
>
> Zach
>
> On Sat, Jan 11, 2025 at 11:21 AM Peter Dimov via SG16
> <sg16_at_[hidden]> wrote:
> >
> > Victor Zverovich wrote:
> > > The usual approach is to provide a char option (string_view in your case) that
> > > works properly in the common and the most important from the future
> > > evolution case of UTF-8 literal encoding. It would also be consistent with
> > > existing exceptions and the decision we made for P3068:
> > > https://github.com/cplusplus/papers/issues/1754#issuecomment-2299368606.
> > > You might want to elaborate why you can't optionally provide a
> > > u8 overload in addition to that.
> >
> > If we base everything on string_view using the literal encoding, and
> > provide an additional u8string_view overload, we'll have to say what
> > happens when that u8 overload is given a string that is not representable
> > in the literal encoding.
> >
> > In these cases, P2996 functions fail.
> >
> > But we can't "fail" here, because throwing a meta::exception is precisely
> > how P2996 functions fail (as proposed in this paper).
> >
> > See also section 2.1 of the paper,
> > https://isocpp.org/files/papers/P3560R0.html#encoding.
> >
> > >
> > > Cheers,
> > > Victor
> > >
> > > On Sat, Jan 11, 2025 at 8:50 AM Barry Revzin via SG16 <sg16_at_[hidden]
> > > <mailto:sg16_at_[hidden]> > wrote:
> > >
> > >
> > > Hey all,
> > >
> > > Peter and I will have a paper in this upcoming mailing, which can be
> > > found here (https://isocpp.org/files/papers/P3560R0.html). We're proposing
> > > that error handling in reflection should use exceptions to be recoverable, now
> > > that it is possible to have recoverable exceptions during constant evaluation.
> > >
> > >
> > > The part that concerns this list is... what type should
> > > std::meta::exception::what() return: std::string_view or std::u8string_view?
> > >
> > >
> > >
> > > * Argument for u8string_view: this is the principled, type system
> > > correct answer.
> > > * Argument for string_view: this is the only type for which there is
> > > absolutely any support whatsoever in the standard library to do anything.
> > >
> > >
> > > As you all know, this is an area in which I have no expertise (neither
> > > current nor, if I'm being honest, desired). This discussion will have to go to
> > > SG16 eventually, so I wanted to just expedite the process.
> > >
> > > As we point out, P2996 used to originally use string_view everywhere
> > > and we changed to provide a dual interface (e.g. identifier_of() and
> > > u8identifier_of() both exist). That's not really feasible for std::meta::exception,
> > > we kind of have to pick one.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > Barry
> > >
> > > --
> > > SG16 mailing list
> > > SG16_at_[hidden] <mailto:SG16_at_[hidden]>
> > > https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> > >
> >
> >
> > --
> > SG16 mailing list
> > SG16_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg16