On 9/1/20 2:14 PM, Aaron Ballman via SG16 wrote:
> On Tue, Sep 1, 2020 at 1:16 PM Martinho Fernandes via SG16
> <sg16_at_[hidden]> wrote:
>>
>> On Tue, Sep 1, 2020 at 7:05 PM Aaron Ballman via SG16 <sg16_at_[hidden]> wrote:
>>> On Tue, Sep 1, 2020 at 12:08 PM Alisdair Meredith via SG16
>>> <sg16_at_[hidden]> wrote:
>>>> For a cross compiler, the basic execution character set should correspond to the target platform, but the diagnostics character set should be for the host?
>>> That matches my understanding.
>>>
>>> I suppose a question I could add is whether anyone would like to see a
>>> new character set introduced for diagnostics. My intuition is that it
>>> would be a pretty heavy hammer to bring to bear and that the basic
>>> source character set is probably Good Enough (tm).
>>>
>> Wouldn't these diagnostics be the place people are more likely to use non-basic source characters, though? When it comes to identifiers people will sometimes compromise and restrict themselves and e.g. avoid diacritics, but in error messages I feel like it makes a lot more sense to want to write with the full expression of their native script.
> I think that's likely a valid point, but I'm struggling to find any
> data that I can point to in the paper. I don't suppose you (or anyone
> in SG16) have insights into how often this comes up in practice? e.g.,
> does someone have evidence that this comes up enough to warrant making
> a diagnostic character set? Does anyone think that would be a worse
> approach than limiting to the basic source character set?

I don't have any data regarding use in practice but my intuition matches
Martinho's.

Assuming a diagnostic character set were specified and that it contained
characters beyond the basic source character set, what guarantees could
be offered? Presentation of the diagnostic may be limited by factors
outside the implementation's control; for example, terminal/console
capabilities. We could state that diagnostic messages must reflect all
message characters outside the basic source character set in some way,
whether via an escape mechanism, substitution of a replacement
character, or some other method.

Perhaps it is useful to think about this more abstractly. Translation
phase 1 doesn't place any restrictions on the program source. Likewise,
diagnostic messages need not have an associated concrete character set;
think of asking your smart speaker to compile a program and how it might
present diagnostics. Perhaps diagnostic generation should be defined as
the inverse of translation phase 1; the input is in the internal
character set (insert reversion of translation phase 5 as necessary) and
the output is analogous to "physical source file characters".

Tom.

>
> Thanks!
>
> ~Aaron
>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16