At the risk of asking a question deemed too nit-picky, I have spent a long time trying to justify (as a single example of something that occurs throughout the standard in different contexts) the following definition of an `integer literal` in §2.14.2 of the C++11 standard, specifically in regards to one detail, the presence of whitespace in the syntax notation itself.

(Note that this example - the definition of an integer literal - is not the point of my question. The point of my question is to ask about the syntax description notation used by the C++ standard *itself*, specifically in regards to whitespace between grammatical category names. The example I give here - the definition of an integer literal - is specifically chosen *only* because it acts as an example that is simple and clear-cut.)

(Abbreviated for concision, from §2.14.2):

```
integer-literal:
    decimal-literal integer-suffix_opt

decimal-literal:
    nonzero-digit
    decimal-literal digit

```

(with `nonzero-digit` and `digit` as expected, [0] 1 ... 9). (Note: The above text is all in italics in the standard.)

This all makes sense to me, assuming that the SPACE between the syntax category descriptives *`decimal-literal`* and *`digit`* is understood to NOT be present in the actual source code, but is only present in the syntax description itself as it appears here in section §2.14.2.

This convention - placing a space between category descriptives within the notation, where it is understood that the space is not to be present in the source code - is used in other places in the specification. The example here is just a clear-cut case where the space is clearly not supposed to be present in the source code. (See addendum to this question for counterexamples from the standard where whitespace or other separator/s *must* be present, or is optional, between category descriptives when those category descriptives are replaced by actual tokens in the source code.)

Again, at the risk of being nit-picky, I cannot find anywhere in the standard a statement of convention that spaces are NOT to be present in the source code when interpreting notation such as in this example.

The standard does discuss notational convention in §1.6.1 (and thereafter). The only relevant text that I can find regarding this is:

> 
> In the syntax notation used in this International Standard, syntactic
>  categories are indicated by italic type, and literal words and
>  characters in constant width type. Alternatives are listed on separate
>  lines except in a few cases where a long set of alternatives is marked
>  by the phrase “one of.”
> 
> 
> 

I would not be so nit-picky; however, I find the notation used within the standard to be somewhat tricky, so I would like to be clear on all of the details. I appreciate anyone willing to take the time to fill me in on this.

**ADDENDUM** In response to comments in which a claim is made similar to "*it's obvious that whitespace should not be included in the final source code, so there's no need for the standard to explicitly state this*": I have chosen a trivial example in this question, where it *is* obvious. There are many cases in the standard where it *isn't* obvious without a. priori knowledge of the language (in my opinion), such as §8.0.4 discussing "const" and "volatile":

```
cv-qualifier-seq:
    cv-qualifier cv-qualifier-seq_opt

```

... Note the *opposite* assumption here (whitespace, or another separator or separators, is *required* in the final source code), but that's not possible to deduce from the syntax notation itself.

There are also cases where a space is *optional*, such as:

```
noptr-abstract-declarator:
    noptr-abstract-declarator_opt parameters-and-qualifiers

```

(In this example, to make a point, I won't give the section number or paraphrase what is being discussed; I'll just ask if it's obvious from the grammar notation itself that, in *this* context, whitespace in the final source code is optional between the tokens.)

I suspect that the comments along these lines - "it's obvious, so that's what it must be" - are the result of the fact that the example I've chosen is so obvious. That's exactly why I chose the example.