P2029R4 ("character escapes") seemingly attempts to introduce new terms #4394
Comments
|
The "string literal" table also needs a similar treatment I think. |
|
I'm also not entirely happy with how the character-literal Table Y uses three different rows for "ordinary","non-encodable","multi" literals, but then uses those same three rows for a single (rowspan=3) cell in the next column. This requires a little too much interpretation for my taste and should be styled more obviously. |
|
This table needed a lot of work to make it narrow enough to fit and keeping the original spirit. I'm not sure what the options are for "styled more obviously". We could consider splitting into two tables, one associating the prefix with the simple term and the character set (one row per prefix) and other one for types and examples. |
|
I was thinking horizontal rules to show cell boundaries, and/or a "}" brace for the rowspanned cell. |
The newly added table lex.ccon.literal from #4371/P2029R4 seems to attempt to define the terms "ordinary characater literal", "wide character literal", "UTF-8 character literal", etc., but the presentation makes this unclear. Usually, definitions appear in plain body text where the context and style makes it clear that a new term is being defined, but the table stands apart from the main text, and so we can no longer rely on this convention.
It seems useful to define the terms in the main text, e.g. by adding a sentence to the new paragraph 2:
"The kind of a character literal [...]
as defined by Table Yas described by Table Y. The following kinds are defined: an ordinary character literal is ...".The text was updated successfully, but these errors were encountered: