Repository navigation
Upper-case vs Lower-case for expressions #3271
Description
Throughout the language part of the standard, arbitrary expressions are introduced in lower-case, .e.g:
The set of potential results of an expression
eis defined as follows:
And arbitrary types are introduced in upper-case, e.g.:
A class type
Tmust be complete if:
Both of those are from [basic.def.odr], but it's consistent throughout the language section.
Much of the new library wording from Ranges breaks this convention by introducing expression in upper-case in all the definitions of the CPOs. For instance, from [range.access.begin]:
The expression
ranges::begin(E)for some subexpressionEis expression-equivalent to:
Is there a particular reason why the Ranges wording uses capital letters for expressions instead of lower-case?
Activity
jensmaurer commentedon Oct 3, 2019
[algorithms] uses "Let$E$ ..." (using E as a meta-variable for an expression) pervasively.
@CaseyCarter, any opinion here?
CaseyCarter commentedon Oct 4, 2019
IIRC [algorithms] inconsistently used both
\tcode{E}and$E$as expression placeholders before applying P0896. We chose to use the former as precedent for the placeholder in the CPO specifications. The change to use$E$consistently throughout [algorithms] happened in San Diego when I was integrating all of the range algorithm specifications into thestdflavors.I have a mild preference for
$E$- whose slanted font makes it "clearly" a meta-syntactic variable - overe- which is itself valid syntax for a C++ expression - as a placeholder, but I'll agree that any consistent style would be an improvement over what's in the working draft right now.jensmaurer commentedon Oct 4, 2019
The general idea for
\tcodevs. (e.g.) math formatting is that the former could be valid source code, given the right environment, whereas the latter is used for meta-variables in other situations, such as "atomic operations" or similar. So, using$E$in the [algorithms] section for stuff that looks like valid code snippets is questionable. However, using lowercase "e" for the CPO specification (in harmony with the core language section) might make sense.jensmaurer commentedon Oct 21, 2019
Editorial meeting:
Deferring.
tkoeppe commentedon Nov 4, 2019
jensmaurer commentedon Nov 4, 2019
Editorial meeting: Use math variables for everything, including types.$T$ primarily, possibly with index, for types. Additionally, use $U$ , $V$ for types unrelated to $T$ . Use $E$ for expressions, possibly with subscript.
\placeholderremains for exposition-only names and forming parts of an identifier. Range-based for: explain range/begin/end as exposition-only identifiers. Usejensmaurer commentedon Nov 19, 2019
See also #326, #3139.