<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang xml:lang>
<head>
  <meta charset="utf-8" />
  <meta name="generator" content="mpark/wg21" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
  <meta name="dcterms.date" content="2024-05-13" />
  <title>Reserve identifiers preceded by `@` for non-ignorable
annotation tokens</title>
  <style>
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.csl-block{margin-left: 1.5em;}
ul.task-list{list-style: none;}
pre > code.sourceCode { white-space: pre; position: relative; }
pre > code.sourceCode > span { display: inline-block; line-height: 1.25; }
pre > code.sourceCode > span:empty { height: 1.2em; }
.sourceCode { overflow: visible; }
code.sourceCode > span { color: inherit; text-decoration: inherit; }
div.sourceCode { margin: 1em 0; }
pre.sourceCode { margin: 0; }
@media screen {
div.sourceCode { overflow: auto; }
}
@media print {
pre > code.sourceCode { white-space: pre-wrap; }
pre > code.sourceCode > span { text-indent: -5em; padding-left: 5em; }
}
pre.numberSource code
{ counter-reset: source-line 0; }
pre.numberSource code > span
{ position: relative; left: -4em; counter-increment: source-line; }
pre.numberSource code > span > a:first-child::before
{ content: counter(source-line);
position: relative; left: -1em; text-align: right; vertical-align: baseline;
border: none; display: inline-block;
-webkit-touch-callout: none; -webkit-user-select: none;
-khtml-user-select: none; -moz-user-select: none;
-ms-user-select: none; user-select: none;
padding: 0 4px; width: 4em;
color: #aaaaaa;
}
pre.numberSource { margin-left: 3em; border-left: 1px solid #aaaaaa; padding-left: 4px; }
div.sourceCode
{ background-color: #f6f8fa; }
@media screen {
pre > code.sourceCode > span > a:first-child::before { text-decoration: underline; }
}
code span { } 
code span.al { color: #ff0000; } 
code span.an { } 
code span.at { } 
code span.bn { color: #9f6807; } 
code span.bu { color: #9f6807; } 
code span.cf { color: #00607c; } 
code span.ch { color: #9f6807; } 
code span.cn { } 
code span.co { color: #008000; font-style: italic; } 
code span.cv { color: #008000; font-style: italic; } 
code span.do { color: #008000; } 
code span.dt { color: #00607c; } 
code span.dv { color: #9f6807; } 
code span.er { color: #ff0000; font-weight: bold; } 
code span.ex { } 
code span.fl { color: #9f6807; } 
code span.fu { } 
code span.im { } 
code span.in { color: #008000; } 
code span.kw { color: #00607c; } 
code span.op { color: #af1915; } 
code span.ot { } 
code span.pp { color: #6f4e37; } 
code span.re { } 
code span.sc { color: #9f6807; } 
code span.ss { color: #9f6807; } 
code span.st { color: #9f6807; } 
code span.va { } 
code span.vs { color: #9f6807; } 
code span.wa { color: #008000; font-weight: bold; } 
code.diff {color: #898887}
code.diff span.va {color: #006e28}
code.diff span.st {color: #bf0303}
</style>
  <style type="text/css">
body {
margin: 5em;
font-family: serif;

hyphens: auto;
line-height: 1.35;
text-align: justify;
}
@media screen and (max-width: 30em) {
body {
margin: 1.5em;
}
}
div.wrapper {
max-width: 60em;
margin: auto;
}

ul {
list-style-type: none;
padding-left: 2.5em;
margin-top: -0.2em;
margin-bottom: -0.2em;
}
ol {
padding-left: 2.5em;
}
a {
text-decoration: none;
color: #4183C4;
}
a.hidden_link {
text-decoration: none;
color: inherit;
}
li {
margin-top: 0.6em;
margin-bottom: 0.6em;
}
h1, h2, h3, h4 {
position: relative;
line-height: 1;
}
a.self-link {
position: absolute;
top: 0;
left: calc(-1 * (3.5rem - 26px));
width: calc(3.5rem - 26px);
height: 2em;
text-align: center;
border: none;
transition: opacity .2s;
opacity: .5;
font-family: sans-serif;
font-weight: normal;
font-size: 83%;
}
a.self-link:hover { opacity: 1; }
a.self-link::before { content: "§"; }
ul > li:before {
content: "\2014";
position: absolute;
margin-left: -1.5em;
}

#TOC ul > li:before {
content: none;
}
#TOC > ul {
padding-left: 0;
}

.toc-section-number {
margin-right: 0.5em;
}
:target { background-color: #C9FBC9; }
:target .codeblock { background-color: #C9FBC9; }
:target ul { background-color: #C9FBC9; }
.abbr_ref { float: right; }
.folded_abbr_ref { float: right; }
:target .folded_abbr_ref { display: none; }
:target .unfolded_abbr_ref { float: right; display: inherit; }
.unfolded_abbr_ref { display: none; }
.secnum { display: inline-block; min-width: 35pt; }
.header-section-number { display: inline-block; min-width: 35pt; }
.annexnum { display: block; }
div.sourceLinkParent {
float: right;
}
a.sourceLink {
position: absolute;
opacity: 0;
margin-left: 10pt;
}
a.sourceLink:hover {
opacity: 1;
}
a.itemDeclLink {
position: absolute;
font-size: 75%;
text-align: right;
width: 5em;
opacity: 0;
}
a.itemDeclLink:hover { opacity: 1; }
span.marginalizedparent {
position: relative;
left: -5em;
}
li span.marginalizedparent { left: -7em; }
li ul > li span.marginalizedparent { left: -9em; }
li ul > li ul > li span.marginalizedparent { left: -11em; }
li ul > li ul > li ul > li span.marginalizedparent { left: -13em; }
div.footnoteNumberParent {
position: relative;
left: -4.7em;
}
a.marginalized {
position: absolute;
font-size: 75%;
text-align: right;
width: 5em;
}
a.enumerated_item_num {
position: relative;
left: -3.5em;
display: inline-block;
margin-right: -3em;
text-align: right;
width: 3em;
}
div.para { margin-bottom: 0.6em; margin-top: 0.6em; text-align: justify; }
div.section { text-align: justify; }
div.sentence { display: inline; }
span.indexparent {
display: inline;
position: relative;
float: right;
right: -1em;
}
a.index {
position: absolute;
display: none;
}
a.index:before { content: "⟵"; }

a.index:target {
display: inline;
}
.indexitems {
margin-left: 2em;
text-indent: -2em;
}
div.itemdescr {
margin-left: 3em;
}
.bnf {
font-family: serif;
margin-left: 40pt;
margin-top: 0.5em;
margin-bottom: 0.5em;
}
.ncbnf {
font-family: serif;
margin-top: 0.5em;
margin-bottom: 0.5em;
margin-left: 40pt;
}
.ncsimplebnf {
font-family: serif;
font-style: italic;
margin-top: 0.5em;
margin-bottom: 0.5em;
margin-left: 40pt;
background: inherit; 
}
span.textnormal {
font-style: normal;
font-family: serif;
white-space: normal;
display: inline-block;
}
span.rlap {
display: inline-block;
width: 0px;
}
span.descr { font-style: normal; font-family: serif; }
span.grammarterm { font-style: italic; }
span.term { font-style: italic; }
span.terminal { font-family: monospace; font-style: normal; }
span.nonterminal { font-style: italic; }
span.tcode { font-family: monospace; font-style: normal; }
span.textbf { font-weight: bold; }
span.textsc { font-variant: small-caps; }
a.nontermdef { font-style: italic; font-family: serif; }
span.emph { font-style: italic; }
span.techterm { font-style: italic; }
span.mathit { font-style: italic; }
span.mathsf { font-family: sans-serif; }
span.mathrm { font-family: serif; font-style: normal; }
span.textrm { font-family: serif; }
span.textsl { font-style: italic; }
span.mathtt { font-family: monospace; font-style: normal; }
span.mbox { font-family: serif; font-style: normal; }
span.ungap { display: inline-block; width: 2pt; }
span.textit { font-style: italic; }
span.texttt { font-family: monospace; }
span.tcode_in_codeblock { font-family: monospace; font-style: normal; }
span.phantom { color: white; }

span.math { font-style: normal; }
span.mathblock {
display: block;
margin-left: auto;
margin-right: auto;
margin-top: 1.2em;
margin-bottom: 1.2em;
text-align: center;
}
span.mathalpha {
font-style: italic;
}
span.synopsis {
font-weight: bold;
margin-top: 0.5em;
display: block;
}
span.definition {
font-weight: bold;
display: block;
}
.codeblock {
margin-left: 1.2em;
line-height: 127%;
}
.outputblock {
margin-left: 1.2em;
line-height: 127%;
}
div.itemdecl {
margin-top: 2ex;
}
code.itemdeclcode {
white-space: pre;
display: block;
}
span.textsuperscript {
vertical-align: super;
font-size: smaller;
line-height: 0;
}
.footnotenum { vertical-align: super; font-size: smaller; line-height: 0; }
.footnote {
font-size: small;
margin-left: 2em;
margin-right: 2em;
margin-top: 0.6em;
margin-bottom: 0.6em;
}
div.minipage {
display: inline-block;
margin-right: 3em;
}
div.numberedTable {
text-align: center;
margin: 2em;
}
div.figure {
text-align: center;
margin: 2em;
}
table {
border: 1px solid black;
border-collapse: collapse;
margin-left: auto;
margin-right: auto;
margin-top: 0.8em;
text-align: left;
hyphens: none; 
}
td, th {
padding-left: 1em;
padding-right: 1em;
vertical-align: top;
}
td.empty {
padding: 0px;
padding-left: 1px;
}
td.left {
text-align: left;
}
td.right {
text-align: right;
}
td.center {
text-align: center;
}
td.justify {
text-align: justify;
}
td.border {
border-left: 1px solid black;
}
tr.rowsep, td.cline {
border-top: 1px solid black;
}
tr.even, tr.odd {
border-bottom: 1px solid black;
}
tr.capsep {
border-top: 3px solid black;
border-top-style: double;
}
tr.header {
border-bottom: 3px solid black;
border-bottom-style: double;
}
th {
border-bottom: 1px solid black;
}
span.centry {
font-weight: bold;
}
div.table {
display: block;
margin-left: auto;
margin-right: auto;
text-align: center;
width: 90%;
}
span.indented {
display: block;
margin-left: 2em;
margin-bottom: 1em;
margin-top: 1em;
}
ol.enumeratea { list-style-type: none; background: inherit; }
ol.enumerate { list-style-type: none; background: inherit; }

code.sourceCode > span { display: inline; }
</style>
  <link href="data:image/x-icon;base64,AAABAAIAEBAAAAEAIABoBAAAJgAAACAgAAABACAAqBAAAI4EAAAoAAAAEAAAACAAAAABACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AIJEAACCRAAAgkQAAIJEAACCRAAAgkQAVoJEAN6CRADegkQAWIJEAACCRAAAgkQAAIJEAACCRAAA////AP///wCCRAAAgkQAAIJEAACCRAAsgkQAvoJEAP+CRAD/gkQA/4JEAP+CRADAgkQALoJEAACCRAAAgkQAAP///wD///8AgkQAAIJEABSCRACSgkQA/IJEAP99PQD/dzMA/3czAP99PQD/gkQA/4JEAPyCRACUgkQAFIJEAAD///8A////AHw+AFiBQwDqgkQA/4BBAP9/PxP/uZd6/9rJtf/bybX/upd7/39AFP+AQQD/gkQA/4FDAOqAQgBc////AP///wDKklv4jlEa/3o7AP+PWC//8+3o///////////////////////z7un/kFox/35AAP+GRwD/mVYA+v///wD///8A0Zpk+NmibP+0d0T/8evj///////+/fv/1sKz/9bCs//9/fr//////+/m2/+NRwL/nloA/5xYAPj///8A////ANKaZPjRmGH/5cKh////////////k149/3UwAP91MQD/lmQ//86rhv+USg3/m1YA/5hSAP+bVgD4////AP///wDSmmT4zpJY/+/bx///////8+TV/8mLT/+TVx//gkIA/5lVAP+VTAD/x6B//7aEVv/JpH7/s39J+P///wD///8A0ppk+M6SWP/u2sf///////Pj1f/Nj1T/2KFs/8mOUv+eWhD/lEsA/8aee/+0glT/x6F7/7J8Rvj///8A////ANKaZPjRmGH/48Cf///////+/v7/2qt//82PVP/OkFX/37KJ/86siv+USg7/mVQA/5hRAP+bVgD4////AP///wDSmmT40ppk/9CVXP/69O////////7+/v/x4M//8d/P//7+/f//////9u7n/6tnJf+XUgD/nFgA+P///wD///8A0ppk+NKaZP/RmWL/1qNy//r07///////////////////////+vXw/9akdP/Wnmn/y5FY/6JfFvj///8A////ANKaZFTSmmTo0ppk/9GYYv/Ql1//5cWm//Hg0P/x4ND/5cWm/9GXYP/RmGH/0ppk/9KaZOjVnmpY////AP///wDSmmQA0ppkEtKaZI7SmmT60ppk/9CWX//OkVb/zpFW/9CWX//SmmT/0ppk/NKaZJDSmmQS0ppkAP///wD///8A0ppkANKaZADSmmQA0ppkKtKaZLrSmmT/0ppk/9KaZP/SmmT/0ppkvNKaZCrSmmQA0ppkANKaZAD///8A////ANKaZADSmmQA0ppkANKaZADSmmQA0ppkUtKaZNzSmmTc0ppkVNKaZADSmmQA0ppkANKaZADSmmQA////AP5/AAD4HwAA4AcAAMADAACAAQAAgAEAAIABAACAAQAAgAEAAIABAACAAQAAgAEAAMADAADgBwAA+B8AAP5/AAAoAAAAIAAAAEAAAAABACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AP///wCCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAAyCRACMgkQA6oJEAOqCRACQgkQAEIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAA////AP///wD///8A////AIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRABigkQA5oJEAP+CRAD/gkQA/4JEAP+CRADqgkQAZoJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAAD///8A////AP///wD///8AgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAA4gkQAwoJEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQAxIJEADyCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAAgkQAAP///wD///8A////AP///wCCRAAAgkQAAIJEAACCRAAAgkQAAIJEAACCRAAWgkQAmIJEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAJyCRAAYgkQAAIJEAACCRAAAgkQAAIJEAACCRAAA////AP///wD///8A////AIJEAACCRAAAgkQAAIJEAACCRAAAgkQAdIJEAPCCRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAP+CRAD/gkQA/4JEAPSCRAB4gkQAAIJEAACCRAAAgkQAAIJEAAD///8A////AP///wD///8AgkQAAIJEAACCRAAAgkQASoJEANKCRAD/gkQA/4JEAP+CRAD/g0YA/39AAP9zLgD/bSQA/2shAP9rIQD/bSQA/3MuAP9/PwD/g0YA/4JEAP+CRAD/gkQA/4JEAP+CRADUgkQAToJEAACCRAAAgkQAAP///wD///8A////AP///wB+PwAAgkUAIoJEAKiCRAD/gkQA/4JEAP+CRAD/hEcA/4BBAP9sIwD/dTAA/5RfKv+viF7/vp56/76ee/+wiF7/lWAr/3YxAP9sIwD/f0AA/4RHAP+CRAD/gkQA/4JEAP+CRAD/gkQArIJEACaBQwAA////AP///wD///8A////AIBCAEBzNAD6f0EA/4NFAP+CRAD/gkQA/4VIAP92MwD/bSUA/6N1Tv/ezsL/////////////////////////////////38/D/6V3Uv9uJgD/dTEA/4VJAP+CRAD/gkQA/4JEAP+BQwD/fUAA/4FDAEj///8A////AP///wD///8AzJRd5qBlKf91NgD/dDUA/4JEAP+FSQD/cy4A/3YyAP/PuKP//////////////////////////////////////////////////////9K7qP94NQD/ciwA/4VJAP+CRAD/fkEA/35BAP+LSwD/mlYA6v///wD///8A////AP///wDdpnL/4qx3/8KJUv+PUhf/cTMA/3AsAP90LgD/4dK+/////////////////////////////////////////////////////////////////+TYxf91MAD/dTIA/31CAP+GRwD/llQA/6FcAP+gWwD8////AP///wD///8A////ANGZY/LSm2X/4ap3/92mcP+wdT3/byQA/8mwj////////////////////////////////////////////////////////////////////////////+LYxv9zLgP/jUoA/59bAP+hXAD/nFgA/5xYAPL///8A////AP///wD///8A0ppk8tKaZP/RmWL/1p9q/9ubXv/XqXj////////////////////////////7+fD/vZyG/6BxS/+gcUr/vJuE//r37f//////////////////////3MOr/5dQBf+dVQD/nVkA/5xYAP+cWAD/nFgA8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/SmWP/yohJ//jo2P//////////////////////4NTG/4JDFf9lGAD/bSQA/20kAP9kGAD/fz8S/+Xb0f//////5NG9/6txN/+LOgD/m1QA/51aAP+cWAD/m1cA/5xYAP+cWADy////AP///wD///8A////ANKaZPLSmmT/0ppk/8+TWf/Unmv//v37//////////////////////+TWRr/VwsA/35AAP+ERgD/g0UA/4JGAP9lHgD/kFga/8KXX/+TRwD/jT4A/49CAP+VTQD/n10A/5xYAP+OQQD/lk4A/55cAPL///8A////AP///wD///8A0ppk8tKaZP/SmmT/y4tO/92yiP//////////////////////8NnE/8eCQP+rcTT/ez0A/3IyAP98PgD/gEMA/5FSAP+USwD/jj8A/5lUAP+JNwD/yqV2/694Mf+HNQD/jkAA/82rf/+laBj/jT4A8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/LiUr/4byY///////////////////////gupX/0I5P/+Wuev/Lklz/l1sj/308AP+QSwD/ol0A/59aAP+aVQD/k0oA/8yoh///////+fXv/6pwO//Lp3v///////Pr4f+oay7y////AP///wD///8A////ANKaZPLSmmT/0ppk/8uJSv/hvJj//////////////////////+G7l//Jhkb/0ppk/96nc//fqXX/x4xO/6dkFP+QSQD/llEA/5xXAP+USgD/yaOA///////38uv/qG05/8ijdv//////8efb/6ZpLPL///8A////AP///wD///8A0ppk8tKaZP/SmmT/zIxO/9yxh///////////////////////7dbA/8iEQf/Sm2X/0Zlj/9ScZv/eqHf/2KJv/7yAQf+XTgD/iToA/5lSAP+JNgD/yKFv/611LP+HNQD/jT8A/8qmeP+kZRT/jT4A8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/Pk1n/1J5q//78+//////////////////+/fv/1aFv/8iEQv/Tm2b/0ppl/9GZY//Wn2z/1pZc/9eldf/Bl2b/kUcA/4w9AP+OQAD/lUwA/59eAP+cWQD/jT8A/5ZOAP+eXADy////AP///wD///8A////ANKaZPLSmmT/0ppk/9KZY//KiEn/8d/P///////////////////////47+f/05tm/8iCP//KiEj/yohJ/8eCP//RmGH//vfy///////n1sP/rXQ7/4k4AP+TTAD/nVoA/5xYAP+cVwD/nFgA/5xYAPL///8A////AP///wD///8A0ppk8tKaZP/SmmT/0ptl/8uLTf/aq37////////////////////////////+/fz/6c2y/961jv/etY7/6Myx//78+v//////////////////////3MWv/5xXD/+ORAD/mFQA/51ZAP+cWAD/nFgA8v///wD///8A////AP///wDSmmTy0ppk/9KaZP/SmmT/0ppk/8mFRP/s1b//////////////////////////////////////////////////////////////////////////////+PD/0JFU/7NzMv+WUQD/kUsA/5tXAP+dWQDy////AP///wD///8A////ANKaZP/SmmT/0ppk/9KaZP/Sm2X/z5NZ/8yMT//z5NX/////////////////////////////////////////////////////////////////9Ofa/8yNUP/UmGH/36p5/8yTWv+qaSD/kksA/5ROAPz///8A////AP///wD///8A0ppk5NKaZP/SmmT/0ppk/9KaZP/TnGf/zY9T/82OUv/t1sD//////////////////////////////////////////////////////+7Yw//OkFX/zI5R/9OcZ//SmmP/26V0/9ymdf/BhUf/ol8R6P///wD///8A////AP///wDSmmQ80ppk9tKaZP/SmmT/0ppk/9KaZP/TnGj/zpFW/8qJSv/dson/8uHS//////////////////////////////////Lj0//etIv/y4lL/86QVf/TnGj/0ppk/9KaZP/RmWP/05xn/9ymdfjUnWdC////AP///wD///8A////ANKaZADSmmQc0ppkotKaZP/SmmT/0ppk/9KaZP/Tm2b/0Zli/8qJSf/NjlH/16Z3/+G8mP/myKr/5siq/+G8mP/Xp3f/zY5S/8qISf/RmGH/05tm/9KaZP/SmmT/0ppk/9KaZP/SmmSm0pljINWdaQD///8A////AP///wD///8A0ppkANKaZADSmmQA0ppkQtKaZMrSmmT/0ppk/9KaZP/SmmT/0ptl/9GYYf/Nj1P/y4lL/8qISP/KiEj/y4lK/82PU//RmGH/0ptl/9KaZP/SmmT/0ppk/9KaZP/SmmTO0ppkRtKaZADSmmQA0ppkAP///wD///8A////AP///wDSmmQA0ppkANKaZADSmmQA0ppkANKaZGzSmmTu0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmTw0ppkcNKaZADSmmQA0ppkANKaZADSmmQA////AP///wD///8A////ANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZBLSmmSQ0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppklNKaZBTSmmQA0ppkANKaZADSmmQA0ppkANKaZAD///8A////AP///wD///8A0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQy0ppkutKaZP/SmmT/0ppk/9KaZP/SmmT/0ppk/9KaZP/SmmT/0ppkvtKaZDbSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkAP///wD///8A////AP///wDSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkXNKaZODSmmT/0ppk/9KaZP/SmmT/0ppk5NKaZGDSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA////AP///wD///8A////ANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkBtKaZIbSmmTo0ppk6tKaZIrSmmQK0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZADSmmQA0ppkANKaZAD///8A////AP/8P///+B///+AH//+AAf//AAD//AAAP/AAAA/gAAAHwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA+AAAAfwAAAP/AAAP/8AAP//gAH//+AH///4H////D//" rel="icon" />
  
  <!--[if lt IE 9]>
    <script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
  <![endif]-->
</head>
<body>
<div class="wrapper">
<header id="title-block-header">
<h1 class="title" style="text-align:center">Reserve identifiers preceded
by <code class="sourceCode cpp"><span class="op">@</span></code> for
non-ignorable annotation tokens</h1>
<table style="border:none;float:right">
  <tr>
    <td>Document #:</td>
    <td>P3254R0</td>
  </tr>
  <tr>
    <td>Date:</td>
    <td>2024-05-13</td>
  </tr>
  <tr>
    <td style="vertical-align:top">Project:</td>
    <td>Programming Language C++</td>
  </tr>
  <tr>
    <td style="vertical-align:top">Audience:</td>
    <td>
      EWG<br>
    </td>
  </tr>
  <tr>
    <td style="vertical-align:top">Reply-to:</td>
    <td>
      Brian Bi<br>&lt;<a href="mailto:bbi10@bloomberg.net" class="email">bbi10@bloomberg.net</a>&gt;<br>
    </td>
  </tr>
</table>
</header>
<div style="clear:both">
<div id="TOC" role="doc-toc">
<h1 id="toctitle">Contents</h1>
<ul>
<li><a href="#abstract" id="toc-abstract"><span class="toc-section-number">1</span> Abstract</a></li>
<li><a href="#introduction" id="toc-introduction"><span class="toc-section-number">2</span> Introduction</a></li>
<li><a href="#prior-art-in-other-programming-languages" id="toc-prior-art-in-other-programming-languages"><span class="toc-section-number">3</span> Prior art in other programming
languages</a></li>
<li><a href="#example-contract-annotations" id="toc-example-contract-annotations"><span class="toc-section-number">4</span> Example: contract
annotations</a></li>
<li><a href="#example-trivial-relocatability" id="toc-example-trivial-relocatability"><span class="toc-section-number">5</span> Example: trivial
relocatability</a></li>
<li><a href="#example-profile-annotations" id="toc-example-profile-annotations"><span class="toc-section-number">6</span> Example: profile
annotations</a></li>
<li><a href="#example-no_unique_address" id="toc-example-no_unique_address"><span class="toc-section-number">7</span> Example: <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code></a></li>
<li><a href="#making-identifier-a-preprocessing-token" id="toc-making-identifier-a-preprocessing-token"><span class="toc-section-number">8</span> Making
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
a preprocessing token</a></li>
<li><a href="#scoped-annotation-keys" id="toc-scoped-annotation-keys"><span class="toc-section-number">9</span> Scoped annotation keys</a></li>
<li><a href="#wording" id="toc-wording"><span class="toc-section-number">10</span> Wording</a></li>
<li><a href="#policy-for-use-of-annotation-keys" id="toc-policy-for-use-of-annotation-keys"><span class="toc-section-number">11</span> Policy for use of
<em>annotation-key</em>s</a></li>
<li><a href="#acknowledgements" id="toc-acknowledgements"><span class="toc-section-number">12</span> Acknowledgements</a></li>
<li><a href="#bibliography" id="toc-bibliography"><span class="toc-section-number">13</span> References</a></li>
</ul>
</div>
<h1 data-number="1" id="abstract"><span class="header-section-number">1</span> Abstract<a href="#abstract" class="self-link"></a></h1>
<p><span class="citation" data-cites="P2558R2">[<a href="https://wg21.link/p2558r2" role="doc-biblioref">P2558R2</a>]</span>, adopted into C++23, added the
<code class="sourceCode cpp"><span class="op">@</span></code> character
to the basic source character set. There are no currently valid tokens
containing this character, other than literals. I argue that using
<code class="sourceCode cpp"><span class="op">@</span></code> to
introduce a non-ignorable annotation is a plausible future use of the
character and give some plausible examples (but do not formally propose
any). In order to leave this syntax space open, I propose that at
present, <code class="sourceCode cpp"><span class="op">@</span></code>
directly followed by an identifier be a single preprocessing token.</p>
<h1 data-number="2" id="introduction"><span class="header-section-number">2</span> Introduction<a href="#introduction" class="self-link"></a></h1>
<p>Attributes were originally envisioned as “a way to open up a new
namespace for keywords reserved to the implementers” and avoid “risk of
collision with existing users’ names” <span class="citation" data-cites="N2224">[<a href="https://wg21.link/n2224" role="doc-biblioref">N2224</a>]</span>. The proposal for attribute
syntax that was ultimately adopted into the Standard, <span class="citation" data-cites="N2761">[<a href="https://wg21.link/n2761" role="doc-biblioref">N2761</a>]</span>, suggested that attributes be
used only for “minor annotations” (and, thus, not completely eliminate
the need to introduce new keywords, or new meanings for existing
keywords, to designate new major features).</p>
<p>Both papers’ objectives have been frustrated to a great extent by the
eventual emergence of the attribute ignorability rule (referred to by
<span class="citation" data-cites="P2552R3">[<a href="https://wg21.link/p2552r3" role="doc-biblioref">P2552R3</a>]</span> as the “Second Ignorability
Rule”). Many minor features are unable to take advantage of the syntax
space that N2224 proposed to make available, and many minor annotations
require (possibly contextual) keywords instead of attributes, which runs
contrary to the guidance in N2761 that features that are “used in
declarations or definitions only”, that are “of use to a limited
audience only”, or that are “minor annotations” be standardized as
attributes rather than keywords.</p>
<p>The use of (possibly contextual) keywords risks not only collisions
with identifiers in pre-existing code, but also collisions with
identifiers that users might eventually try to use. Such collisions can
be resolved by a normative disambiguation rule, but the result might not
be what the user expected, and the specification effort alone might be
considerable. See Section 10 of <span class="citation" data-cites="P2786R5">[<a href="https://wg21.link/p2786r5" role="doc-biblioref">P2786R5</a>]</span> for an example of this
phenomenon; I will discuss this example in more depth shortly.</p>
<p>I give some examples of how the Standard might benefit from the use
of <code class="sourceCode cpp"><span class="op">@</span></code>
followed by an <em>identifier</em> to introduce a non-ignorable
annotation: that is, a syntactic entity similar to an attribute, but
with mandatory semantics specified by the Standard. In effect, every
occurrence of
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
would be a keyword and all such keywords would be initially reserved for
future standardization (that is, ill formed) until they are claimed by
future proposals.</p>
<h1 data-number="3" id="prior-art-in-other-programming-languages"><span class="header-section-number">3</span> Prior art in other programming
languages<a href="#prior-art-in-other-programming-languages" class="self-link"></a></h1>
<p>The <code class="sourceCode cpp"><span class="op">@</span></code>
character is most closely associated with the Objective-C programming
language. Several Objective-C keywords start with the
<code class="sourceCode cpp"><span class="op">@</span></code> character,
which clearly marks them as keywords. In addition, the fact that a
keyword such as
<code class="sourceCode cpp"><span class="op">@</span>property</code>
starts with the
<code class="sourceCode cpp"><span class="op">@</span></code> character
avoids the risk of changing the meaning of any C code that might use
<code class="sourceCode cpp">property</code> as an ordinary identifier.
The usage of the
<code class="sourceCode cpp"><span class="op">@</span></code> character
by Objective-C is therefore similar to what this paper suggests should
be the future use of
<code class="sourceCode cpp"><span class="op">@</span></code> by C++.
(Objective-C also uses
<code class="sourceCode cpp"><span class="op">@</span></code> as an
operator for creating literals, but I am not aware of any interest in
introducing a similar feature in C++.)</p>
<p>In Java, syntactic constructs that start with the
<code class="sourceCode cpp"><span class="op">@</span></code> sign are
called <em>annotations</em>. Java annotations are similar to C++
attributes in that the information they provide is usually not essential
to the meaning of a program, and some annotations have built-in
semantics while others are given a meaning only by non-standard tools
that consume source code or reflect on Java programs. However, unlike
C++ attributes, Java annotations can have mandatory semantics, such as
<code class="sourceCode cpp"><span class="op">@</span>Override</code>
(similar to the
<code class="sourceCode cpp"><span class="kw">override</span></code>
contextual keyword in C++). Java’s use of the
<code class="sourceCode cpp"><span class="op">@</span></code> character
is therefore similar to what this paper suggests should be the future
use of <code class="sourceCode cpp"><span class="op">@</span></code> by
C++.</p>
<p>In Python,
<code class="sourceCode cpp"><span class="op">@</span></code> introduces
a <em>decorator</em>, which is a function that will be applied to the
definition of a class or function, possibly changing its functionality.
Python allows any function to be used as a decorator, and, therefore,
there is no list of standard decorators; any built-in function could
theoretically be used as a decorator. Some of the functions that are
most well-known for their use as decorators include
<code class="sourceCode cpp"><span class="op">@</span>classmethod</code>,
<code class="sourceCode cpp"><span class="op">@</span>staticmethod</code>,
<code class="sourceCode cpp"><span class="op">@</span>property</code>,
and <code class="sourceCode cpp"><span class="op">@</span>functools<span class="op">.</span>cache</code>.
All of these examples arguably change the properties of the decorated
entity in a major way, and their C++ analogues, if they existed, would
therefore not satisfy the criteria in N2761 to be considered as minor
annotations. Nevertheless, they do usually have the property that the
decorated definition would make sense without the decorator, with a
slightly different meaning. I believe that programmers who are familiar
with Python decorators would find it natural if C++ used
<code class="sourceCode cpp"><span class="op">@</span></code> to
introduce non-ignorable annotations that can be applied to functions and
classes. Eventually, C++ could introduce annotations that actually
function similarly to Python decorators, using syntax like <code class="sourceCode cpp"><span class="op">@</span>reflect<span class="op">(</span>func<span class="op">)</span></code>,
which would apply <code class="sourceCode cpp">func</code> to the
reflection of the annotated entity.</p>
<p>The C# programming language uses
<code class="sourceCode cpp"><span class="op">@</span></code> to
introduce an identifier: for example,
<code class="sourceCode cpp"><span class="op">@</span>class</code> means
an identifier spelled
<code class="sourceCode cpp"><span class="kw">class</span></code>,
rather than the keyword
<code class="sourceCode cpp"><span class="kw">class</span></code>. Such
usage would conflict with the objective of this paper, so I do not
propose it.</p>
<h1 data-number="4" id="example-contract-annotations"><span class="header-section-number">4</span> Example: contract annotations<a href="#example-contract-annotations" class="self-link"></a></h1>
<p>According to <span class="citation" data-cites="P2885R3">[<a href="https://wg21.link/p2885r3" role="doc-biblioref">P2885R3</a>]</span>, some users considered the
attribute-like syntax proposed for Contracts to be too “heavy”, but
others “consider the particular way in which the attribute-like syntax
stands out visually to be a benefit, as it creates a clear separation
between contract-checking annotations and other C++ code”. Note that the
attribute-<em>like</em> syntax that was proposed was not actually an
<em>attribute</em> syntax due to the presence of a colon after the
identifier <code class="sourceCode cpp">pre</code>,
<code class="sourceCode cpp">post</code>, or
<code class="sourceCode cpp"><span class="ot">assert</span></code>;
therefore, it could not violate the attribute ignorability rule.
However, the visual similarity of the attribute-like syntax to actual
attributes could lead some readers to assume that a contract annotation
is ignorable, and this was one of the reasons why some members of SG21
disliked the attribute-like syntax.</p>
<p>The “natural” syntax that ultimately gained consensus in SG21 did not
suffer from the aforementioned issues with the attribute-like syntax,
but also (in my opinion) does not provide the benefit of standing out
visually and creating a clear separation in the way that the
attribute-like syntax would have. The natural syntax also suffers from
two disadvantages, discussion of which consumed a significant amount of
SG21 time:</p>
<ul>
<li>It was not immediately obvious whether implementations would easily
be able to parse the natural syntax, <em>i.e.</em>, determine when
exactly the identifier <code class="sourceCode cpp">pre</code> or
<code class="sourceCode cpp">post</code> has the meaning of introducting
a contract annotation, rather than being an ordinary
<em>identifier</em>.</li>
<li>The natural syntax for an assertion cannot use the
<code class="sourceCode cpp"><span class="ot">assert</span></code>
identifier, <em>i.e.</em>, the form <code class="sourceCode cpp"><span class="ot">assert</span><span class="op">(</span></code><em>conditional-expression</em><code class="sourceCode cpp"><span class="op">)</span></code>,
due to conflict with the
<code class="sourceCode cpp"><span class="ot">assert</span></code> macro
in the Standard Library. Where assertion is present as a language
feature in programming languages other than C++, it is overwhelmingly
likely to be spelled simply
<code class="sourceCode cpp"><span class="ot">assert</span></code>, and
it is unfortunate that C++ has to spell it
<code class="sourceCode cpp">contract_assert</code> instead for backward
compatibility.</li>
</ul>
<p>Rostislav Khlebnikov suggested, but did not seriously propose, that
contract annotations be introduced by the
<code class="sourceCode cpp"><span class="op">@</span></code> keyword,
<em>e.g.</em>, <code class="sourceCode cpp"><span class="op">@</span>pre<span class="op">(</span>x <span class="op">&gt;</span> <span class="dv">0</span><span class="op">)</span></code>
or <code class="sourceCode cpp"><span class="op">@</span>assert<span class="op">(</span>x <span class="op">&gt;</span> <span class="dv">0</span><span class="op">)</span></code>.
The latter would technically <em>still</em> be a breaking change, as I
will discuss later, but one that is very unlikely to impact real code;
it would therefore open up the possibility of using the preferred
spelling
<code class="sourceCode cpp"><span class="ot">assert</span></code>
rather than the more verbose
<code class="sourceCode cpp">contract_assert</code>. In addition, this
syntax for Contracts would, like the natural syntax, avoid the
disadvantages of the the attribute-like syntax, but would also have the
benefit of standing out visually.</p>
<p>I do not actually propose to change the current consensus syntax for
Contracts, but merely to provide an example of an option that could have
been seriously considered if
<code class="sourceCode cpp"><span class="op">@</span></code> were
already considered by EWG to be suitable for introducing non-ignorable
annotations.</p>
<h1 data-number="5" id="example-trivial-relocatability"><span class="header-section-number">5</span> Example: trivial relocatability<a href="#example-trivial-relocatability" class="self-link"></a></h1>
<p><span class="citation" data-cites="P2786R5">[<a href="https://wg21.link/p2786r5" role="doc-biblioref">P2786R5</a>]</span> proposes a mechanism to
explicitly specify whether a class type is trivially relocatable: <code class="sourceCode cpp"><span class="kw">struct</span> A trivially_relocatable <span class="op">{}</span>;</code>
would define <code class="sourceCode cpp">A</code> to be a trivially
relocatable class type, while <code class="sourceCode cpp"><span class="kw">struct</span> A trivially_relocatable<span class="op">(</span>b<span class="op">)</span> <span class="op">{}</span>;</code>
would make <code class="sourceCode cpp">A</code> trivially relocatable
if and only if <code class="sourceCode cpp">b</code> is
<code class="sourceCode cpp"><span class="kw">true</span></code> when
considered as a contextually conveted constant expression. An issue with
this contextual keyword is the type of “vexing parse” discussed in
Section 10 of that paper:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode cpp"><code class="sourceCode cpp"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> A trivially_relocatable<span class="op">(</span><span class="dt">bool</span><span class="op">(</span>my_constexpr_value<span class="op">))</span> <span class="op">{</span></span>
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Is this a class definition, or the definition of a function named</span></span>
<span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a>    <span class="co">// `trivially_relocatable` with an elaborated type specifier for its return</span></span>
<span id="cb1-4"><a href="#cb1-4" aria-hidden="true" tabindex="-1"></a>    <span class="co">// type and a `bool` parameter named `my_constexpr_value`?</span></span>
<span id="cb1-5"><a href="#cb1-5" aria-hidden="true" tabindex="-1"></a><span class="op">}</span>;</span></code></pre></div>
<p>The EWG decided that the new feature should not change the meaning of
any code, even hypothetical code, that is currently well-defined, so
that the above definition should be considered to define a function
whenever it is a syntactically valid function definition. The CWG felt
that requiring implementations to potentially consider the full content
of the definition (<em>i.e.</em> everything between the braces) in order
to determine whether the definition is of a class or a function would be
unreasonably burdensome, and a considerable amount of effort was
expended in determining how to word a more reasonable disambiguation
rule that would not require taking into account anything after the
opening brace; this direction is pending EWG approval. Even assuming
that the revised version of the disambiguation rule is approved by the
EWG and the CWG, I consider it unfortunate that the choices are to
either change the meaning of currently well-defined code (not approved
by the EWG) or to disambiguate in the direction that is far less likely
to have been intended by the user.</p>
<p>Consider, instead, if
<code class="sourceCode cpp">trivially_relocatable</code> were to be
preceded by the
<code class="sourceCode cpp"><span class="op">@</span></code> character.
The syntactic ambiguity would be entirely avoided, and the presence of
<code class="sourceCode cpp"><span class="op">@</span></code> would
alert the reader to the fact that <code class="sourceCode cpp"><span class="op">@</span>trivially_relocatable</code>
is a minor but non-ignorable annotation to the class definition. I do
not actually propose in this paper to introduce the <code class="sourceCode cpp"><span class="op">@</span>trivially_relocatable</code>
syntax, but merely give it as an example of an option that the authors
of P2786 might have considered if the EWG were known to be open to using
<code class="sourceCode cpp"><span class="op">@</span></code> to
introduce non-ignorable annotations.</p>
<h1 data-number="6" id="example-profile-annotations"><span class="header-section-number">6</span> Example: profile annotations<a href="#example-profile-annotations" class="self-link"></a></h1>
<p><span class="citation" data-cites="P2816R0">[<a href="https://wg21.link/p2816r0" role="doc-biblioref">P2816R0</a>]</span> proposes an approach to
improving the safety of the C++ language by defining a set of
<em>profiles</em>, each of which enables a particular set of
compile-time and/or run-time checks, and providing the ability to
annotate C++ code to specify the profiles that would apply to it. The
authors of P2816R0 have not yet published a revision that proposes a
concrete syntax for profile annotations, but there has been some recent
discussion about syntax on the SG23 reflector. Some Committee members
have expressed opposition to the idea of using an attribute-based syntax
for profile annotations because such annotations will be ignored by
older compilers, and one member suggested the syntax <code class="sourceCode cpp"><span class="op">@</span>enable<span class="op">(</span>ranges<span class="op">)</span></code>
as an example of a non-ignorable syntax for enabling the
<code class="sourceCode cpp">ranges</code> profile.<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a></p>
<h1 data-number="7" id="example-no_unique_address"><span class="header-section-number">7</span> Example: <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code><a href="#example-no_unique_address" class="self-link"></a></h1>
<p>The <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>
attribute was intended to satisfy the attribute ignorability rule <span class="citation" data-cites="P0840R0">[<a href="https://wg21.link/p0840r0" role="doc-biblioref">P0840R0</a>]</span>. The Standard allows but does
not require a member declared with <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>
to share its storage with another subobject; therefore, it might appear
that the ignorability rule is satisfied. However, because <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>
normatively makes a non-static data member a potentially-overlapping
subobject (§<span>6.7.2
<a href="https://wg21.link/N4981#intro.object">[intro.object]</a><a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a></span>p7.2), and the property of
being potentially-overlapping triggers certain core language rules even
if the implementation ignores the attribute for layout purposes, <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>
as initially specified was not ignorable. One reason for
non-ignorability was resolved by <span class="citation" data-cites="CWG2759">[<a href="https://wg21.link/cwg2759" role="doc-biblioref">CWG2759</a>]</span>, while another, described in
<span class="citation" data-cites="CWG2866">[<a href="https://wg21.link/cwg2866" role="doc-biblioref">CWG2866</a>]</span>, is still open, and there is no
consensus within the CWG about how to resolve it. In addition, Microsoft
will not implement <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>
with useful semantics until the next time a business decision can be
taken to change their ABI in a non-backward-compatible fashion.</p>
<p>Due to the aforementioned problems with the <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>
attribute, some interest has been expressed on the EWG reflector in the
idea of deprecating this attribute and replacing it with a keyword.
Since this feature is minor enough to have been made an attribute in the
first place, it may be a good candidate for a non-ignorable annotation,
<code class="sourceCode cpp"><span class="op">@</span>no_unique_address</code>.
Such an annotation would still not have a mandatory effect on class
layout, but would have mandatory effects on constructs that depend on
whether a subobject is potentially-overlapping, and there would be no
backward compatibility issue preventing any implementation from
providing useful semantics for it.</p>
<h1 data-number="8" id="making-identifier-a-preprocessing-token"><span class="header-section-number">8</span> Making
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
a preprocessing token<a href="#making-identifier-a-preprocessing-token" class="self-link"></a></h1>
<p>Since this paper doesn’t propose any actual concrete annotations, all
code that uses
<code class="sourceCode cpp"><span class="op">@</span></code> outside a
comment or literal would continue to be ill formed if this proposal were
to be adopted. One might therefore wonder whether this paper proposes
any normative changes to the Standard at all. The answer is yes, because
in current C++,
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
is two <em>preprocessing-tokens</em>, not one (§<span>5.4
<a href="https://wg21.link/N4981#lex.pptoken">[lex.pptoken]</a></span>).
The implications of this fact are illustrated by the following
example.</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode cpp"><code class="sourceCode cpp"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#define NDEBUG</span></span>
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im">&lt;cassert&gt;</span></span>
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im">&lt;print&gt;</span></span>
<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a><span class="pp">#define STR</span><span class="op">(</span>X<span class="op">)</span><span class="pp"> #</span>X</span>
<span id="cb2-5"><a href="#cb2-5" aria-hidden="true" tabindex="-1"></a><span class="pp">#define STR2</span><span class="op">(</span>X<span class="op">)</span><span class="pp"> </span>STR<span class="op">(</span>X<span class="op">)</span></span>
<span id="cb2-6"><a href="#cb2-6" aria-hidden="true" tabindex="-1"></a><span class="pp">#define A </span><span class="op">@</span>assert<span class="op">(</span><span class="kw">true</span><span class="op">)</span></span>
<span id="cb2-7"><a href="#cb2-7" aria-hidden="true" tabindex="-1"></a><span class="pp">#define M </span>STR2<span class="op">(</span>A<span class="op">)</span></span>
<span id="cb2-8"><a href="#cb2-8" aria-hidden="true" tabindex="-1"></a><span class="dt">int</span> main<span class="op">()</span> <span class="op">{</span></span>
<span id="cb2-9"><a href="#cb2-9" aria-hidden="true" tabindex="-1"></a>    std<span class="op">::</span>print<span class="op">(</span><span class="st">&quot;{}&quot;</span>, M<span class="op">)</span>;</span>
<span id="cb2-10"><a href="#cb2-10" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
<p>In current C++, the above program prints <code class="sourceCode cpp"><span class="op">@((</span><span class="dt">void</span><span class="op">)</span><span class="dv">0</span><span class="op">)</span></code>:
prefixing
<code class="sourceCode cpp"><span class="ot">assert</span></code> with
<code class="sourceCode cpp"><span class="op">@</span></code> does not
prevent expansion of
<code class="sourceCode cpp"><span class="ot">assert</span></code>. If
<code class="sourceCode cpp"><span class="op">@</span>assert</code> were
a single preprocessing token, then it would not be the name of a
function-like macro, so the above program would print <code class="sourceCode cpp"><span class="op">@</span>assert<span class="op">(</span><span class="kw">true</span><span class="op">)</span></code>.</p>
<p>The benefit of making
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
a single token is that whenever a concrete annotation is eventually
introduced into the language, it could be used in any C++ program even
if the <em>identifier</em> is already defined as a macro. Although SG21
has already decided that contract assertions should be introduced via a
new keyword, <code class="sourceCode cpp">contract_assert</code>, it is
possible that there will be enthusiasm for the additional syntax
<code class="sourceCode cpp"><span class="op">@</span>assert</code> at a
later time.</p>
<p>I do not propose to make a lone
<code class="sourceCode cpp"><span class="op">@</span></code> ill formed
as a preprocessing token. Under this proposal,
<code class="sourceCode cpp"><span class="op">@</span></code> that is
not immediately followed by an identifier would remain a preprocessing
token (see the grammar in §<span>5.4
<a href="https://wg21.link/N4981#lex.pptoken">[lex.pptoken]</a></span>)
and would therefore be eligible to be concatenated with an identifier
using the <code class="sourceCode cpp"><span class="pp">#</span><span class="er">#</span></code>
operator.</p>
<p>This change to the C++ preprocessor may cause a one-time breakage
now, <em>i.e.</em>, for programs that actually rely on something like
the behavior above, where <code class="sourceCode cpp"><span class="op">@((</span><span class="dt">void</span><span class="op">)</span><span class="dv">0</span><span class="op">)</span></code>
is printed. I consider it highly unlikely that any programs that are not
compiler test suites are actually relying on this. However, the expected
number of such programs in existence is more likely to increase than
decrease over time, so if the Committee wants to maximize the ability to
leave
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
available for future keywords denoting non-ignorable annotations, I
believe that
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
should be changed to be a single token now.</p>
<p>Note that making
<code class="sourceCode cpp"><span class="op">@</span></code><em>identifier</em>
a single token will introduce a difference between the C++ preprocessor
and the C preprocessor. While the difference is unfortunate, we have
precedent in the form of user-defined literals; see §<span>C.6.2
<a href="https://wg21.link/N4981#diff.cpp03.lex">[diff.cpp03.lex]</a></span>p2.<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a></p>
<h1 data-number="9" id="scoped-annotation-keys"><span class="header-section-number">9</span> Scoped annotation keys<a href="#scoped-annotation-keys" class="self-link"></a></h1>
<p>An open question is whether scoped annotation keys should be
supported, such as <code class="sourceCode cpp"><span class="op">@</span>gnu<span class="op">::</span>foo</code>,
for introducing vendor-specific annotations. Such vendor-specific
annotations would necessarily differ from hypothetical standard
annotations, since a standard annotation that is not recognized by the
implementation would be ill formed, whereas a vendor-specific annotation
that is not recognized by the implementation should be ignored, since
making it ill formed would fragment the C++ language into
vendor-specific dialects. Thus, it may be undesirable to use the same
syntax for both ignorable and non-ignorable annotations (depending on
whether the name following the
<code class="sourceCode cpp"><span class="op">@</span></code> is
qualified). Introducing ignorable, vendor-specific annotations also
makes the feature harder to explain:
<code class="sourceCode cpp"><span class="op">@</span></code> could no
longer be described as a character that is simply present in the
spelling of certain keywords (as in Objective-C).</p>
<p>If we introduce scoped annotation keys, then we must take care to
prevent a certain lexical ambiguity: for example, if
<code class="sourceCode cpp"><span class="op">@</span>foo</code> is a
valid annotation key whose syntax does not have any kind of argument
clause, then <code class="sourceCode cpp"><span class="op">@</span>foo<span class="op">::</span>bar x;</code>
could mean that
<code class="sourceCode cpp"><span class="op">@</span>foo</code> is an
annotation of the declaration
<code class="sourceCode cpp"><span class="op">::</span>bar x;</code>, or
that <code class="sourceCode cpp"><span class="op">@</span>foo<span class="op">::</span>bar</code>
is an annotation of the expression statement
<code class="sourceCode cpp">x;</code>. To resolve this ambiguity, we
could simply say that
<code class="sourceCode cpp"><span class="op">@</span></code> followed
by a qualified name is also a single preprocessing token; the “maximal
munch” rule (§<span>5.4
<a href="https://wg21.link/N4981#lex.pptoken">[lex.pptoken]</a></span>p3.3)
then implies that <code class="sourceCode cpp"><span class="op">@</span>foo<span class="op">::</span>bar x;</code>
is always interpreted as <code class="sourceCode cpp"><span class="op">@</span>foo<span class="op">::</span>bar</code>
annotating <code class="sourceCode cpp">x;</code>. This choice implies
that whitespace must be used in order to obtain the other
interpretation, <em>i.e.</em>, <code class="sourceCode cpp"><span class="op">@</span>foo <span class="op">::</span>bar x;</code>.</p>
<p>Since vendor-specific attributes are not subject to the ignorability
rule, implementations already have full freedom to give such attributes
any semantics they consider desirable. For example, the syntax <code class="sourceCode cpp"><span class="op">@</span>gnu<span class="op">::</span>foo</code>
does not need to be supported because GCC can already define <code class="sourceCode cpp"><span class="op">[[</span><span class="ex">gnu::foo</span><span class="op">]]</span></code>
to mean whatever they want.</p>
<p>However, the one reason why we might want to consider supporting
vendor-specific annotations (which must, as explained above, be
ignorable) is for purposes of reflection. For example, consider a
reflection-based static analysis library,
<code class="sourceCode cpp">foo</code>, which might wish to make use of
the annotation <code class="sourceCode cpp"><span class="op">@</span>foo<span class="op">::</span>bar</code>
and benefit from a guarantee that this annotation will be visible to
reflection. It might not be possible to use attributes for this purpose,
since Clang discards unrecognized attributes during parsing, and they do
not appear in the AST.</p>
<p>Considering the possible disadvantages described above, and the fact
that some additional design questions remain for how to specify
ignorable scoped annotations (for example, what kinds of argument
clauses they could take), I do not take a position in this proposal as
to whether ignorable scoped annotations should be allowed at all. A
future proposal to introduce ignorable scoped annotations should
consider design alternatives, such as an unscoped annotation key that
can be used to introduce arbitrary information into the AST
(<em>e.g.</em>, <code class="sourceCode cpp"><span class="op">@</span>annotate<span class="op">(</span>foo<span class="op">::</span>bar, <span class="st">&quot;value_for_bar&quot;</span><span class="op">))</span></code>.
Instead, I propose to leave this design space open by specifying that
anything that looks like a scoped annotation key is ill formed.</p>
<h1 data-number="10" id="wording"><span class="header-section-number">10</span> Wording<a href="#wording" class="self-link"></a></h1>
<p>Edit §<span>5.4
<a href="https://wg21.link/N4981#lex.pptoken">[lex.pptoken]</a></span>:</p>
<blockquote>
<div class="line-block"><em>preprocessing-token</em>:<br />
    <em>header-name</em><br />
    <em>import-keyword</em><br />
    <em>module-keyword</em><br />
    <em>export-keyword</em><br />
    <em>identifier</em><br />
    <span class="add" style="color: #006e28"><ins><em>annotation-key</em></ins></span><br />
    <em>pp-number</em><br />
    <em>character-literal</em><br />
    <em>user-defined-character-literal</em><br />
    <em>string-literal</em><br />
    <em>user-defined-string-literal</em><br />
    <em>preprocessing-op-or-punc</em><br />
    each non-whitespace character that cannot be one of the above</div>
<p>Each preprocessing token that is converted to a token shall have the
lexical form of a keyword, <span class="add" style="color: #006e28"><ins>an annotation key,</ins></span> an
identifier, a literal, or an operator or punctuator.</p>
<p>[…] The categories of preprocessing tokens are: header names,
placeholder tokens produced by preprocessing
<code class="sourceCode cpp"><span class="kw">import</span></code> and
<code class="sourceCode cpp"><span class="kw">module</span></code>
directives (<em>import-keyword</em>, <em>module-keyword</em>, and
<em>export-keyword</em>), identifiers, <span class="add" style="color: #006e28"><ins>annotation keys,</ins></span> preprocessing
numbers, character literals (including user-defined character-literals),
string literals (including user-defined string literals), preprocessing
operators and punctuators, and single non-whitespace characters that do
not lexically match the other preprocessing token categories. […]</p>
<p>[…]</p>
</blockquote>
<p>Edit §<span>5.6
<a href="https://wg21.link/N4981#lex.token">[lex.token]</a></span>:</p>
<div class="add" style="color: #006e28">

<blockquote>
<div class="line-block"><em>annotation-key:</em><br />
    <code class="sourceCode default">@</code> <em>identifier</em><br />
    <em>annotation-key</em> <code class="sourceCode default">::</code>
<em>identifier</em></div>
</blockquote>

</div>
<blockquote>
<div class="line-block"><em>token:</em><br />
    <em>identifier</em><br />
    <em>keyword</em><br />
    <span class="add" style="color: #006e28"><ins><em>annotation-key</em></ins></span><br />
    <em>literal</em><br />
    <em>operator-or-punctuator</em></div>
<p>There are <span class="rm" style="color: #bf0303"><del>five</del></span><span class="add" style="color: #006e28"><ins>six</ins></span> kinds of tokens:
identifiers, keywords, <span class="add" style="color: #006e28"><ins>annotation keys,</ins></span> literals,
operators, and other separators. […]<br />
[<em>Note 1</em>: […] — <em>end note</em>]<br />
<span class="add" style="color: #006e28"><ins>[<em>Note 2</em>: All
<em>annotation-key</em>s appearing outside an <em>attribute</em>
([dcl.attr.grammar]) are reserved for future standardization. — end
note]</ins></span></p>
</blockquote>
<p>In §<span>15.11
<a href="https://wg21.link/N4981#cpp.predefined">[cpp.predefined]</a></span>,
add a feature test macro named
<code class="sourceCode cpp">__cpp_annotations</code>.</p>
<h1 data-number="11" id="policy-for-use-of-annotation-keys"><span class="header-section-number">11</span> Policy for use of
<em>annotation-key</em>s<a href="#policy-for-use-of-annotation-keys" class="self-link"></a></h1>
<p>If EWG reaches consensus to forward the wording changes proposed by
this paper to CWG, I propose that an additional poll be taken on whether
EWG encourages work in the direction of proposing a policy for EWG to
adopt with respect to criteria for determining whether an
<em>annotation-key</em> (as opposed to a regular keyword) is appropriate
syntax for a new non-ignorable feature. I do not plan to formally
propose any such policy myself, but I would like to suggest that some of
the criteria listed in N2761 might be a good starting point.</p>
<h1 data-number="12" id="acknowledgements"><span class="header-section-number">12</span> Acknowledgements<a href="#acknowledgements" class="self-link"></a></h1>
<p>Rostislav Khlebnikov suggested this usage for the
<code class="sourceCode cpp"><span class="op">@</span></code> character.
Lauri Vasama pointed out the potential lexical ambiguity arising from
scoped annotation keys.</p>
<h1 data-number="13" id="bibliography"><span class="header-section-number">13</span> References<a href="#bibliography" class="self-link"></a></h1>
<div id="refs" class="references csl-bib-body hanging-indent" data-entry-spacing="1" role="doc-bibliography">
<div id="ref-CWG2759" class="csl-entry" role="doc-biblioentry">
[CWG2759] Richard Smith. 2020-11-10. [[no_unique_address] and common
initial sequence. <a href="https://wg21.link/cwg2759"><div class="csl-block">https://wg21.link/cwg2759</div></a>
</div>
<div id="ref-CWG2866" class="csl-entry" role="doc-biblioentry">
[CWG2866] Brian Bi. 2023-11-12. Observing the effects of <code class="sourceCode cpp"><span class="op">[[</span><span class="at">no_unique_address</span><span class="op">]]</span></code>.
<a href="https://wg21.link/cwg2866"><div class="csl-block">https://wg21.link/cwg2866</div></a>
</div>
<div id="ref-N2224" class="csl-entry" role="doc-biblioentry">
[N2224] Alisdair Meredith. 2007-03-12. Seeking a Syntax for Attributes
in C++09. <a href="https://wg21.link/n2224"><div class="csl-block">https://wg21.link/n2224</div></a>
</div>
<div id="ref-N2761" class="csl-entry" role="doc-biblioentry">
[N2761] J. Maurer, M. Wong. 2008-09-18. Towards support for attributes
in C++ (Revision 6). <a href="https://wg21.link/n2761"><div class="csl-block">https://wg21.link/n2761</div></a>
</div>
<div id="ref-P0840R0" class="csl-entry" role="doc-biblioentry">
[P0840R0] Richard Smith. 2017-10-16. Lamguage support for empty objects.
<a href="https://wg21.link/p0840r0"><div class="csl-block">https://wg21.link/p0840r0</div></a>
</div>
<div id="ref-P2552R3" class="csl-entry" role="doc-biblioentry">
[P2552R3] Timur Doumler. 2023-06-14. On the ignorability of standard
attributes. <a href="https://wg21.link/p2552r3"><div class="csl-block">https://wg21.link/p2552r3</div></a>
</div>
<div id="ref-P2558R2" class="csl-entry" role="doc-biblioentry">
[P2558R2] Steve Downey. 2023-02-08. Add @, $, and ` to the basic
character set. <a href="https://wg21.link/p2558r2"><div class="csl-block">https://wg21.link/p2558r2</div></a>
</div>
<div id="ref-P2786R5" class="csl-entry" role="doc-biblioentry">
[P2786R5] Mungo Gill, Alisdair Meredith. 2024-04-09. Trivial
Relocatability For C++26. <a href="https://wg21.link/p2786r5"><div class="csl-block">https://wg21.link/p2786r5</div></a>
</div>
<div id="ref-P2816R0" class="csl-entry" role="doc-biblioentry">
[P2816R0] Bjarne Stroustrup, Gabriel Dos Reis. 2023-02-16. Safety
Profiles: Type-and-resource Safe programming in ISO Standard C++. <a href="https://wg21.link/p2816r0"><div class="csl-block">https://wg21.link/p2816r0</div></a>
</div>
<div id="ref-P2885R3" class="csl-entry" role="doc-biblioentry">
[P2885R3] Timur Doumler, Joshua Berne, Gašper Ažman, Andrzej
Krzemieński, Ville Voutilainen, Tom Honermann. 2023-10-05. Requirements
for a Contracts syntax. <a href="https://wg21.link/p2885r3"><div class="csl-block">https://wg21.link/p2885r3</div></a>
</div>
</div>
<section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
<hr />
<ol>
<li id="fn1"><p>On the other hand, some members consider it desirable
for profile annotations to be ignored by older compilers. I would not
expect a syntax that uses the
<code class="sourceCode cpp"><span class="op">@</span></code> character
to appeal to those members.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2"><p>All citations to the Standard are to working draft N4981
unless otherwise specified.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn3"><p>While the indicated paragraph of the Standard discusses
a difference between the preprocessor of current C++ and that of C++03,
the same difference exists between C++ and C, because C does not have
user-defined literals.<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
</div>
</div>
</body>
</html>
