Zach Laine 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().

This paper proposes a modification to P2996, and as such, it needs to be
consistent with the rest of P2996, not consistent with something else specified
somewhere else.

> I see no need to change that here.

That's not a change. It's a new component, part of reflection.

> You get
> whatever encoding the implementation produces, for all what()
> implementations, for this and all other exceptions.

In practice, for std::exception::what(), you get no encoding guarantees at all.
Even "the implementation" produces a mixture of encodings, and user code
may and does produce whatever it wants.

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

I can only repeat my below answer here, including the plea to read section
2.1 of the paper.

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