Date: Mon, 13 Jan 2025 10:07:08 -0600
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
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
Received on 2025-01-13 16:07:22