On Thu, 23 Jan 2020 at 23:32, Jens Maurer <Jens.Maurer@gmx.net> wrote:
On 23/01/2020 23.19, Corentin Jabot wrote:
>
>
> On Thu, Jan 23, 2020, 21:57 Jens Maurer via SG16 <sg16@lists.isocpp.org <mailto:sg16@lists.isocpp.org>> wrote:
>
>     Hi,
>
>     We talked quite a bit about this paper in the teleconference.
>
>     I have another concern: The core language defines the
>     terms "execution character set" and "execution wide-character set"
>     in [lex.charset].
>
>     The wording in the paper should use exactly these phrases, with
>     an appropriate cross-reference.
>
>     Given these definitions, I'm a bit concern about the name of
>     the member function "literal".  If it wants to talk about the
>     execution character set, it should state so in its name.
>
>
> While we can bikeshed the particulars, the paper does explain the names chosen.

That's one part of my concern; the other is the expression
of the specification.  If the core language specifies a term
that has the right semantics, the library wording should use it.

That's a good point.
I'll make sure the wording use the right term
 

> The core wording is not necessarily intuitive for users.

Mission accomplished.

> The core wording also assumes (it doesn't really have a choice) that the execution encoding is a subset of the encoding associated to the current locale).

I don't understand that sentence.
I thought locales and encoding should (conceptually) get
a divorce.

Yep, but separate paper!
Right now we can only speak about locale associated encoding in the wording.
 

Or is your concern that "execution character set" sounds like a
compile-time constant, whereas the environment's character set
might actually be runtime-defined (e.g. xterm for UTF-8 vs. Latin-1)?

If so, do you suggest changes to the definition of
"execution character set"?  Put differently, do you anticipate that
literal() might return a text_encoding that is different from the
execution character set?  Or is there some haziness between
"character set" and "encoding" in the core language?  After all,
when translating literals to the execution character set, the
compiler actually has to pick an encoding, because it has
to put string literals down to program memory.

No, the wording is fine.
The underlying issue is that (to the best of my understanding, this is your area of expertise, not mine!), the standard consider both compilation/ constant evaluation and runtime as "execution".
In practice of course if the "execution" encoding is set to be UTF-8 during compilation but later executed on an ebcdic machine, attempting to do any kind of text i/o will result in mojibake, as the information of what the execution encoding was is lost (hence this proposal), and no conversion is implicitly performed.
 
In that context, I am afraid that "execution" will be understood at "runtime" by many people.
But again, you are right that I should have used "execution encoding" in my wording - independently of the user facing method name.

It's something that Steve is also looking into http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1859r0.html
  

Jens