Subject: Re: Concatenating unicode string literals
From: Tom Honermann (tom_at_[hidden])
Date: 2020-07-10 01:00:19
On 7/9/20 5:07 PM, Jens Maurer wrote:
> On 09/07/2020 21.44, Tom Honermann wrote:
>> On 7/9/20 3:16 PM, Jens Maurer wrote:
>>> On 09/07/2020 18.28, Tom Honermann wrote:
>>>> On 7/8/20 3:15 PM, Jens Maurer wrote:
>>>>> Since all four well-known C++ implementations appear to
>>>>> produce an error for the test cases at
>>>>> I'm fine with specifying these as ill-formed.
>>>> I'm fine with that as well.
>>>> Jens, would you consider such a change as evolutionary given that we don't know of any implementations (so far) that actually support these concatenations?
>>> I'm not the one to make the call here.
>> I know, I was just looking for an opinion from a CWG regular.Â Thank you.
>>> Strictly speaking, it changes the standard for some feature from
>>> "conditionally-supported" to "ill-formed", which does sound a bit
>>> evolutionary, in particular since we depart a little further from
>>> C here.
>>> However, personally, I'm ok with this going to Core right away.
>>> JF should make the call here.
>> We don't have a paper for this yet.Â If we have a volunteer to write a
>> paper to make concatenations involving mixed L"", u8"", u"", and U""
>> concatenations ill-formed, I'll be happy to discuss with JF with
>> encouragement to take it straight to Core.
> Here you are:
> I think the overlap with P2029 is very manageable, so this can
> go ahead regardless.
Some minor suggestions for the paper:
- Make the compiler-explorer URL an actual link.
- Mention that the SDCC C compiler does actually support mixed
concatenations as reported on the WG14 mailing list
(http://open-std.org/jtc1/sc22/wg14/18105).Â I verified that SDCC
version 4 does accept such code (version 3.5 does not), though I didn't
verify the behavior.
- Explicitly state the four major C++ compilers (there could be more (or
less) in the future and the compiler-explorer link may go dark some day!).
SG16 list run by firstname.lastname@example.org