[dcl.init.string] Reword character array initialization

[Eisenwave]

This edit greatly compactifies the current wording. The issue with the status quo is that it contains a massive clause of:

X, Y, Z, or W may be initialized by A, B, C, or D respectively

Such a clause is difficult for the reader to follow, and it's easy to make a mistake when matching B to Y etc. What the paragraph is saying, in essence, is that an array may be initialized by a string literal of the same type. These types are clearly defined in [lex.string.literal], and could be used in this paragraph.

We can simply say that

X is initialized by a string-literal of type X

Some care is required due to the string-literals being arrays of const characters.

Furthermore, the wording of

or by an appropriately-typed string-literal enclosed in braces

is quite verbose, and could be simplified to "optionally brace-enclosed". This is just as clear, but much more concise.

[JohelEGP]

Just an editorial review.

[Eisenwave]

I was overthinking it. After the most recent changes, the more complicated rules weren't even much less verbose, so I've decided to dumb it down and make a list instead. This feels so much better.

One noteworthy issue that the first and third bullet have to be assumed to be additive rules by the reader. If the reader assumes that the bullets are mutually exclusive, and I don't think they reasonably should, then this list of items is contradictory.

[jensmaurer]

The current state is, once more, a situation where we put bullets in front of sentences without them being conditions or similar. They aren't even mutually exclusive. I'm not convinced this is an improvement.

I did think, however, that the intermediate state that got rid of repeating all the types was a mild improvement, avoiding repetition. We won't get rid of the special case regardless.

[Eisenwave]

The current state is, once more, a situation where we put bullets in front of sentences without them being conditions or similar. They aren't even mutually exclusive. I'm not convinced this is an improvement.

They could be made made a conjunction if they were combined with and, which would be a better justification for a list.

that the intermediate state that got rid of repeating all the types was a mild improvement

I think it was a mild improvement too, but still needlessly complex. Ideally, the reader should be able to tell at first glance which array belongs to what literal. Something like a list of bullets or a table is ideal.

Also, I think they can be made mutually exclusive if they are phrased in terms of which literal can be used to initialize what array, i.e.:

An optionally brace-enclosed string-literal may be used to initialize arrays of the following types:

• an ordinary string literal may be used to initialize an array of ordinary character type;
• a wide string literal may be used to initialize an array of wchar_t;
• a UTF-8 string literal may be used to initialize an array of char8_t, char, and of unsigned char;
• a UTF-16 string literal may be used to initialize an array of char16_t; and
• a UTF-32 string literal may be used to initialize an array of char32_t.

@jensmaurer What do you think about that? Now bullets are mutually exclusive, and a conjunction.

We won't get rid of the special case regardless.

Not entirely, but now that special case is contained in the bullet for UTF-8 string literals, and doesn't break mutual exclusion.

[Eisenwave]

We can also formally define what it means for a string literal to be appropriately typed for the initialization of an array, and that would be a disjunction with three bullets. That term is used colloquially throughout the standard anyway.

Then, say that an array may be initialized by an appropriately typed string literal. This would actually shorten wording in other places too.

Idea

An object of type "array of T may be initialized by an optionally brace-enclosed string-literal of type "array of const U" if:

• T and U are the same type;
• T is an ordinary character type ([basic.fundamental]) and U is char; or
• T is char or unsigned char, and U is char8_t.

• the first bullet covers all the common cases
• the second bullet covers arrays of unsigned char or signed char being initialized by an ordinary literal
• the third bullet covers the special cases for UTF-8 literals

This covers everything very compactly, and is very implementer-friendly because it's close to how you would check for validity in a compiler.

[Eisenwave]

I think @jensmaurer was on the right track. The intermediate version had potential, and if we just drop the use of the defined terms for string literals and focus on the types, everything can be elegantly described in three concise, disjunctive bullets.