Also confirming that this resolves my original concern, that implementations
were free to define nonsensical unicode string literal concatenations. One
solution, as taken by this paper, is to simply outlaw them altogether. While
my preferred answer would be to define unicode contanations in the
“obvious” way, this paper resolves my primary concern without making more
work for anyone else, so I am good with it.

AlisdairM

> On Jul 9, 2020, at 22:07, Jens Maurer <Jens.Maurer_at_[hidden]> 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
>>>>> https://compiler-explorer.com/z/4NDo-4
>>>>> 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.
>>
>> Agreed.
>>
>> 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:
>
> https://wiki.edg.com/pub/Wg21summer2020/SG16/concatenation.html
>
> I think the overlap with P2029 is very manageable, so this can
> go ahead regardless.
>
> Jens