Если вы зададите вопрос, который считается слишком ничтожным, я долгое время пытался оправдать (как один пример того, что встречается во всем стандарте в разных контекстах) следующее определение integer literal в §2.14.2 стандарта С++ 11, особенно в отношении одной детали, наличие пробелов в самой синтаксической нотации.
(Обратите внимание, что этот пример - определение целочисленного литерала - не является точкой моего вопроса. Пункт моего вопроса - спросить о нотации описания синтаксиса, используемой самим стандартом С++, особенно в отношении пробелов между имена грамматической категории. Приведенный здесь пример - определение целочисленного литерала - специально выбран только потому, что он действует как простой и понятный пример.)
(Сокращенное для заключения, из п. 2.2.14):
integer-literal:
decimal-literal integer-suffix_opt
decimal-literal:
nonzero-digit
decimal-literal digit
(с nonzero-digit и digit, как ожидалось, [0] 1... 9). (Примечание. Вышеупомянутый текст выделен курсивом в стандарте.)
Это все имеет смысл для меня, если предположить, что SPACE между описаниями описания синтаксиса decimal-literal и digit понимается как НЕ присутствующий в фактическом исходном коде, но присутствует только в самом описании синтаксиса, поскольку он появляется здесь, в разделе §2.14.2.
Это соглашение - помещение пробела между описаниями категорий в пределах обозначений, где понимается, что пространство не должно присутствовать в исходном коде, - используется в других местах спецификации. Пример здесь - это просто четкий случай, когда пространство явно не должно присутствовать в исходном коде. (См. Дополнение к этому вопросу для контрпримеров из стандарта, где пробелы или другие разделители /s должны присутствовать или не являются обязательными для описания описаний категорий, когда эти описатели категорий заменяются фактическими токенами в исходном коде.)
Опять же, рискуя быть ничтожным, я не могу найти нигде в стандарте утверждение соглашения о том, что пробелы НЕ должны присутствовать в исходном коде при интерпретации обозначений, таких как в этом примере.
В стандарте обсуждается условное обозначение в п. 1.6.1 (и после этого). Единственный актуальный текст, который я могу найти по этому поводу:
В синтаксической нотации, используемой в этом Международном стандарте, синтаксический категории обозначаются курсивом, а буквальные слова и символов в типе постоянной ширины. Альтернативы перечислены на отдельных линий, за исключением нескольких случаев, когда отмечен длинный набор альтернатив по фразе "один из".
Я не был бы таким ничтожным; однако, я считаю, что обозначения, используемые в стандарте, несколько сложны, поэтому я хотел бы четко рассказать обо всех деталях. Я ценю любого, кто хочет потратить время, чтобы наполнить меня этим.
ДОБАВЛЕНИЕ В ответ на комментарии, в которых претензия сделана аналогично "очевидно, что пробелы не должны включаться в конечный исходный код, поэтому нет необходимости, чтобы стандарт явно указывал это",: Я выбрал тривиальный пример в этом вопросе, где это очевидно. В стандарте есть много случаев, когда это не очевидно без а. априорное знание языка (на мой взгляд), например, § 8.0.4, обсуждение "const" и "volatile":
cv-qualifier-seq:
cv-qualifier cv-qualifier-seq_opt
... Обратите внимание на противоположное предположение здесь (пробел или другой разделитель или разделители требуется в конечном исходном коде), но это невозможно сделать из самой синтаксической нотации.
Существуют также случаи, когда пространство необязательно, например:
noptr-abstract-declarator:
noptr-abstract-declarator_opt parameters-and-qualifiers
(В этом примере, чтобы сделать точку, я не буду указывать номер раздела или перефразировать то, что обсуждается, я просто спрошу, очевидно ли это из самой грамматической нотации, что в этом контексте пробелы в конечный исходный код является необязательным между токенами.)
Я подозреваю, что комментарии по этим строкам - "это очевидно, так, что это должно быть" - являются результатом того, что выбранный мной пример настолько очевиден. Именно поэтому я выбрал этот пример.