> Peter:
> What should the following code do?

I think (1) is the only acceptable option because all the rest are
inconsistent with existing std::format overloads.

> “std::locale in its current form is pretty much useless,” may be a true
statement but it doesn’t help me make progress.


Maybe we are trying to make "progress" in the wrong direction? We don't
have to quickly hack something together for new std::format overloads. We
didn't have a chance to look at locale in C++20 but now is a great time.

> Corentin:
> Converting between UTF-X and UTF-Y is a lossless operation.

Only valid ones. There is still a question of handling transcoding errors.

> what is it that we gain by not allowing format(u8"{}", u"");
and format(u8"{}", U"");?

We gain consistency between all std::format overloads, simple
specification, not having to deal with transcoding errors. I am not
suggesting that it shouldn't be possible but that it should be explicit,
e.g.

  format(u8"{}", xcode(u""))

With explicit approach you can easily configure error handling.

> we could provide only the u8 overload

Sure provided that we have transcoding facilities. I don't think u16 and
u32 overloads are particularly useful since you can't do much with the
result.

> mandates that the existing locale be specialize for char8_t

If this specialization inherits all existing locale problems then I think
it's not a good idea.

- Victor

On Mon, Apr 19, 2021 at 3:18 AM Corentin Jabot via SG16 <
sg16_at_[hidden]> wrote:

> Talking with Peter, we realized we could provide only the u8 overload and
> mandates that the existing locale be specialize for char8_t
> We believe this would
>
> - Satisfy Victor's excellent remark about the need not to be
> gratuitously inconsistent
> - Put minimum strain on implementers
> - Let us move forward with having a Unicode overload in 23.
>
>
>
>
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>