Tom Honermann wrote:

> If we want to provide implicit behavior, we can't ignore the locale encoding
> concerns without introducing inconsistency in the library.

Without introducing _consistency_ in the library, you mean; using the literal
encoding as the intermediate is how the wide case already works.

> It isn't a matter of wanting to support it. I feel a strong obligation to ensure
> existing locale dependent code continues to be maintainable. There are
> multiple ecosystems that depend on it.

I'm somewhat unconvinced that the example you showed represents a
real practical need, because I don't believe anyone in the world needs
an ASCII message in English mixed with Shift-JIS month names in Japanese.

In practice, the message is also in Japanese, and the literal encoding is
also Shift-JIS.

Although you could I suppose make the same case by only using
punctuation and whitespace in your character literals.

Note that we don't propose any breaking changes here (* well, I do propose
one, but it doesn't and cannot affect this case.)

We only propose that we don't need to support future UTF-8-aware
programs using newer library facilities such as char8_t* trying to use
this outdated mechanism. This is new code; there's no backward
compatibility here.

If you output a char8_t* to std::cout, we assume that you want the
new shiny future and not the old busted approach.

(*) I'd like us to additionally fix inserting char[] to wcout to not use
widen(), but transcode from the narrow literal encoding to the wide
literal encoding independent of the imbued locale.

This is a breaking change but I think its impact will be much more
limited both because nobody uses wcout and because any existing
working code must not have used a multibyte encoding.