<!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="2023-10-10" />
  <title>Library Evolution Policies</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 { } /* Normal */
      code span.al { color: #ff0000; } /* Alert */
      code span.an { } /* Annotation */
      code span.at { } /* Attribute */
      code span.bn { color: #9f6807; } /* BaseN */
      code span.bu { color: #9f6807; } /* BuiltIn */
      code span.cf { color: #00607c; } /* ControlFlow */
      code span.ch { color: #9f6807; } /* Char */
      code span.cn { } /* Constant */
      code span.co { color: #008000; font-style: italic; } /* Comment */
      code span.cv { color: #008000; font-style: italic; } /* CommentVar */
      code span.do { color: #008000; } /* Documentation */
      code span.dt { color: #00607c; } /* DataType */
      code span.dv { color: #9f6807; } /* DecVal */
      code span.er { color: #ff0000; font-weight: bold; } /* Error */
      code span.ex { } /* Extension */
      code span.fl { color: #9f6807; } /* Float */
      code span.fu { } /* Function */
      code span.im { } /* Import */
      code span.in { color: #008000; } /* Information */
      code span.kw { color: #00607c; } /* Keyword */
      code span.op { color: #af1915; } /* Operator */
      code span.ot { } /* Other */
      code span.pp { color: #6f4e37; } /* Preprocessor */
      code span.re { } /* RegionMarker */
      code span.sc { color: #9f6807; } /* SpecialChar */
      code span.ss { color: #9f6807; } /* SpecialString */
      code span.st { color: #9f6807; } /* String */
      code span.va { } /* Variable */
      code span.vs { color: #9f6807; } /* VerbatimString */
      code span.wa { color: #008000; font-weight: bold; } /* Warning */
      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: 2em;
margin-top: -0.2em;
margin-bottom: -0.2em;
}
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;
}
: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">Library Evolution
Policies</h1>
<h3 class="subtitle" style="text-align:center">The rationale and process
of setting a policy for the Standard Library</h3>
<table style="border:none;float:right">
  <tr>
    <td>Document #:</td>
    <td>P2267R0</td>
  </tr>
  <tr>
    <td>Date:</td>
    <td>2023-10-10</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>
      WG21<br>
      Library Evolution Work Group<br>
    </td>
  </tr>
  <tr>
    <td style="vertical-align:top">Reply-to:</td>
    <td>
      Inbal Levi<br>&lt;<a href="mailto:sinbal2l@gmail.com" class="email">sinbal2l@gmail.com</a>&gt;<br>
      Ben Craig<br>&lt;<a href="mailto:ben.craig@gmail.com" class="email">ben.craig@gmail.com</a>&gt;<br>
      Fabio Fracassi<br>&lt;<a href="mailto:fabio@fracassi.de" class="email">fabio@fracassi.de</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="#introduction" id="toc-introduction"><span class="toc-section-number">1</span> Introduction<span></span></a></li>
<li><a href="#motivation-and-scope" id="toc-motivation-and-scope"><span class="toc-section-number">2</span> Motivation and
Scope<span></span></a>
<ul>
<li><a href="#what-is-a-policy" id="toc-what-is-a-policy"><span class="toc-section-number">2.1</span> What is a
policy<span></span></a></li>
<li><a href="#rationale-for-setting-policies" id="toc-rationale-for-setting-policies"><span class="toc-section-number">2.2</span> Rationale for setting
policies<span></span></a>
<ul>
<li><a href="#pros-for-setting-policies-for-the-standard-library" id="toc-pros-for-setting-policies-for-the-standard-library"><span class="toc-section-number">2.2.1</span> Pros for setting policies for
the standard library<span></span></a></li>
<li><a href="#cons-for-setting-policies-for-the-standard-library" id="toc-cons-for-setting-policies-for-the-standard-library"><span class="toc-section-number">2.2.2</span> Cons for setting policies for
the standard library<span></span></a></li>
<li><a href="#summary" id="toc-summary"><span class="toc-section-number">2.2.3</span> Summary<span></span></a></li>
</ul></li>
</ul></li>
<li><a href="#impact-on-the-standard" id="toc-impact-on-the-standard"><span class="toc-section-number">3</span> Impact On the
Standard<span></span></a></li>
<li><a href="#proposal" id="toc-proposal"><span class="toc-section-number">4</span> Proposal<span></span></a>
<ul>
<li><a href="#requirements-from-policy-papers-and-discussions" id="toc-requirements-from-policy-papers-and-discussions"><span class="toc-section-number">4.1</span> Requirements From Policy Papers
and Discussions<span></span></a>
<ul>
<li><a href="#requirements-from-a-policy-paper" id="toc-requirements-from-a-policy-paper"><span class="toc-section-number">4.1.1</span> Requirements from a policy
paper<span></span></a></li>
<li><a href="#the-process-of-setting-a-policy" id="toc-the-process-of-setting-a-policy"><span class="toc-section-number">4.1.2</span> The process of setting a
policy<span></span></a></li>
<li><a href="#the-process-of-modifying-a-policy" id="toc-the-process-of-modifying-a-policy"><span class="toc-section-number">4.1.3</span> The process of modifying a
policy<span></span></a></li>
<li><a href="#the-process-of-removing-a-policy" id="toc-the-process-of-removing-a-policy"><span class="toc-section-number">4.1.4</span> The process of removing a
policy<span></span></a></li>
<li><a href="#excluding-a-paper-from-applying-a-specific-policy" id="toc-excluding-a-paper-from-applying-a-specific-policy"><span class="toc-section-number">4.1.5</span> Excluding a paper from applying
a specific policy<span></span></a></li>
</ul></li>
<li><a href="#wording-for-sd-9" id="toc-wording-for-sd-9"><span class="toc-section-number">4.2</span> Wording for SD-9<span></span></a>
<ul>
<li><a href="#what-are-standard-library-policies" id="toc-what-are-standard-library-policies">What are Standard Library
Policies<span></span></a></li>
<li><a href="#motivation-for-standard-library-policies" id="toc-motivation-for-standard-library-policies">Motivation for
Standard Library Policies<span></span></a></li>
<li><a href="#excluding-a-proposal-from-applying-a-policy" id="toc-excluding-a-proposal-from-applying-a-policy">Excluding a
proposal from applying a policy<span></span></a></li>
<li><a href="#list-of-standard-library-policies" id="toc-list-of-standard-library-policies">List of Standard Library
Policies<span></span></a></li>
</ul></li>
</ul></li>
<li><a href="#acknowledgements" id="toc-acknowledgements"><span class="toc-section-number">5</span>
Acknowledgements<span></span></a></li>
<li><a href="#appendix-a" id="toc-appendix-a"><span class="toc-section-number">6</span> Appendix A<span></span></a>
<ul>
<li><a href="#policy-examples-not-proposed-in-this-document" id="toc-policy-examples-not-proposed-in-this-document"><span class="toc-section-number">6.1</span> Policy Examples (NOT proposed in
this document)<span></span></a></li>
<li><a href="#statistics-of-the-stadard-library" id="toc-statistics-of-the-stadard-library"><span class="toc-section-number">6.2</span> Statistics of the Stadard
Library<span></span></a>
<ul>
<li><a href="#disclaimers" id="toc-disclaimers"><span class="toc-section-number">6.2.1</span>
Disclaimers<span></span></a></li>
<li><a href="#examples-table-1" id="toc-examples-table-1"><span class="toc-section-number">6.2.2</span> Examples (Table
1)<span></span></a></li>
</ul></li>
</ul></li>
<li><a href="#bibliography" id="toc-bibliography"><span class="toc-section-number">7</span> References<span></span></a></li>
</ul>
</div>
<h1 data-number="1" id="introduction"><span class="header-section-number">1</span> Introduction<a href="#introduction" class="self-link"></a></h1>
<p>Discussion of the necessity of policies for the standard library has
been going on for many years.</p>
<p>There have been a few papers addressing different aspects of it:
<span class="citation" data-cites="P0684R2">[<a href="#ref-P0684R2" role="doc-biblioref">P0684R2</a>]</span>, <span class="citation" data-cites="P1655R0">[<a href="#ref-P1655R0" role="doc-biblioref">P1655R0</a>]</span>, <span class="citation" data-cites="library-design-guidelines">[<a href="#ref-library-design-guidelines" role="doc-biblioref">library-design-guidelines</a>]</span>, <span class="citation" data-cites="P2148R0">[<a href="#ref-P2148R0" role="doc-biblioref">P2148R0</a>]</span>, and others.</p>
<p>Note that the <span class="citation" data-cites="requirements">[<a href="#ref-requirements" role="doc-biblioref">requirements</a>]</span>
section which appears in the beginning of the standard library section
of the C++ working draft does not conflict with policies as the policies
are focused on Library API.</p>
<p>This paper aims to survey the pros and cons of policies, and set up a
process for setting and modifying a policy for the C++ standard
library.</p>
<h1 data-number="2" id="motivation-and-scope"><span class="header-section-number">2</span> Motivation and Scope<a href="#motivation-and-scope" class="self-link"></a></h1>
<p>The standard library is a resource shared by the C++ community. As
such, it contains parts which should support functionality from
different domains.</p>
<p>At the same time, consistency is very important, as it allows users
to have expectations while using different parts of the standard
library.</p>
<p>This paper aims to define what a policy is, what’s the scope in which
it applies and how to build consensus for it.</p>
<h2 data-number="2.1" id="what-is-a-policy"><span class="header-section-number">2.1</span> What is a policy<a href="#what-is-a-policy" class="self-link"></a></h2>
<p>A “policy”, as discussed in this document, is any technical rule or
technical guideline, which should be followed, as a general rule, by
authors of proposals of <strong>FUTURE</strong> utilities for the C++
standard library.</p>
<p>A “utility” can be a container, an algorithm, an output / logging
facility (std::format), a function, a header, or any other logical unit
proposed to the standard library as a paper. A policy can be applied to
existing utilities, but that will require an explicit paper.</p>
<p>In this document we only discuss the process and meaning, and do not
propose any specific policies, but examples of such may be: Mark all
constructors or only single parameter constructors as
<code class="sourceCode default">explicit</code>, use hidden friends for
ADL detection, etc. A list of examples of possible policies (Which are
NOT proposed in this paper) is given in <a href="#appendix-a">Appendix
A</a>.</p>
<p>A policy has to be described clearly and provide coherent guideline
for authors. The policy description can leave no room for
interpretation, so that even if a utility does not follow a certain
policy, we will have a clear understanding of what is the policy which
is violated and how.</p>
<h2 data-number="2.2" id="rationale-for-setting-policies"><span class="header-section-number">2.2</span> Rationale for setting
policies<a href="#rationale-for-setting-policies" class="self-link"></a></h2>
<p>We see both pros and cons to this approach, the following sections we
will describe them.</p>
<h3 data-number="2.2.1" id="pros-for-setting-policies-for-the-standard-library"><span class="header-section-number">2.2.1</span> Pros for setting policies for
the standard library<a href="#pros-for-setting-policies-for-the-standard-library" class="self-link"></a></h3>
<p>We believe the following should be considered as upsides:</p>
<h4 data-number="2.2.1.1" id="policies-create-uniformity-in-users-expectations-from-the-behaviour-of-different-parts-of-the-standard-library"><span class="header-section-number">2.2.1.1</span> Policies create uniformity
in users’ expectations from the behaviour of different parts of the
standard library<a href="#policies-create-uniformity-in-users-expectations-from-the-behaviour-of-different-parts-of-the-standard-library" class="self-link"></a></h4>
<p>The current state of the library is inconsistent. As of now, users
have to be familiar with the details of a utility in order to use
it.</p>
<p>We see a lot of value in making the standard library more coherent
going FORWARD.</p>
<p>“Policies”, as suggested in this document should be applied to future
proposals. While we encourage papers which suggest applying policies as
a fix to already existing utilites, this is <strong>out of scope for
this proposal</strong>.</p>
<p>Increasing consistency will have positive impact on multiple aspects,
including: teachability, and consistency of code design throughout code
bases.</p>
<p>“<a href="#statistics-of-the-stadard-library">Statistics of the
Stadard Library</a>” under <a href="#appendix-a">Appendix A</a> presents
statistics for existing features in the standard library, to demonstrate
inconsistencies.(NOTE: we do not suggests any changes for these features
in this document, just demonstrate which type of inconsistencies
<strong>may</strong> be decreased by setting Policies for
<strong>future</strong> standard library utils).</p>
<h4 data-number="2.2.1.2" id="policies-save-time-for-both-authors-and-the-committee"><span class="header-section-number">2.2.1.2</span> Policies save time for both
authors and the committee<a href="#policies-save-time-for-both-authors-and-the-committee" class="self-link"></a></h4>
<p>With policies, authors can know what is expected of the paper before
it reaches LEWG. This can save time, by avoiding repeating the same
guidance to different authors. Moreover, in the current process, it is
not uncommon for authors of a proposal to get opposite and conflicting
guidelines between different versions of a proposal, even without new
information coming up. The reason being that the room may contain a
different audience in each meeting. Having to re-iterate previously
proposed directions can be a source of frustration and can be very time
consuming for the authors, without adding to the quality of the
proposal. We understand that in some cases going back from a change may
be needed, and that this is part of the process, but we believe policies
will be able to minimize this phenomenon, as authors will know, at least
for some parts of the proposal, what they are expected to do.</p>
<p>Another topic that is time-consuming is locating and fixing bugs in
the standard. More often then not, a discussion on a proposal focuses on
specific topics and avoids iterating over other aspects of the proposal
(either due to time constrains, or because the attendees don’t have
strong opinions on it). This can result in bugs, discovered later by LWG
(in charge of library wording) or, worst case, after the standard is
shiped and published. By providing guidance to the authors in advance,
we can make sure things are less likely to “fall between the cracks”. We
believe this will help not only to save LEWG’s time but also to save
LWG’s and the working draft editors’ time, as well as the time of the
committee as a whole.</p>
<h4 data-number="2.2.1.3" id="policies-need-to-be-created-from-a-shared-knowledge-base"><span class="header-section-number">2.2.1.3</span> Policies need to be created
from a shared knowledge base<a href="#policies-need-to-be-created-from-a-shared-knowledge-base" class="self-link"></a></h4>
<p>As of now, discussions on “policy” level topics can happen at
different times and in different rooms (not just in LEWG, but also in
SGs), as they can be “spontaneously sparked” by a specific topic in the
paper discussed. This has two main disadvantages:</p>
<ol type="1">
<li>Not all the stake-holders can be in the room, as the discussion is
not always announced in advance.</li>
<li>It is not possible to be in all the rooms at once, the knowledge and
guidelines tend to be sparse, and to be passed by second and
third-hand.</li>
</ol>
<p>Setting “formal” discussions in which a specific policy will be
discussed helps in collecting the input of all the committee members and
stake-holders, and can help with minimizing the amount of things left up
for interpretation of the attendees, and misunderstandings that can
result from such interpretations.</p>
<h4 data-number="2.2.1.4" id="policies-make-the-standardization-process-friendly-for-newcomers"><span class="header-section-number">2.2.1.4</span> Policies make the
standardization process friendly for newcomers<a href="#policies-make-the-standardization-process-friendly-for-newcomers" class="self-link"></a></h4>
<p>In the current state, newcomers who would like to make a proposal to
the standard library have no way of knowing “common guidelines” apart
from going over all of the minutes from previous discussions (and even
then, not everything is documented). This is a very bad way to preserve
knowledge. Apart from being time consuming, learning from the minutes
can lead to wrong outcomes, as minutes can be misinterpreted. We believe
that there’s a lot of value in making sure newcomers can benefit from
the committee’s “shared knowledge base”. This will save time both for
the authors, and for the committee.</p>
<h3 data-number="2.2.2" id="cons-for-setting-policies-for-the-standard-library"><span class="header-section-number">2.2.2</span> Cons for setting policies for
the standard library<a href="#cons-for-setting-policies-for-the-standard-library" class="self-link"></a></h3>
<p>We believe the following should be considered as downsides:</p>
<h4 data-number="2.2.2.1" id="policies-may-push-aside-domains-which-are-in-a-minority-representation-in-the-committee"><span class="header-section-number">2.2.2.1</span> Policies may “push aside”
domains which are in a minority representation in the committee<a href="#policies-may-push-aside-domains-which-are-in-a-minority-representation-in-the-committee" class="self-link"></a></h4>
<p>Some technical guidelines are not fit for all the users of C++. We
believe that, unless we take an approach of “lowest common denominator”
some parts of the standard can and should support these domains. This is
true not just for policy discussions, but as a general property of the
current process, as “counting votes” does. To avoid the majority vote
running over the minority vote, we propose that a paper will be able to
bypass a policy, by providing a rationale for it. We describe the
details in section “<a href="#excluding-a-paper-from-applying-a-specific-policy">Excluding a
paper from applying a specific policy</a>” in the proposal section, but
we believe this is an important part of the process.</p>
<h4 data-number="2.2.2.2" id="policies-may-enforce-wrong-technical-solutions-for-some-utilities-proposed-to-the-standard-library"><span class="header-section-number">2.2.2.2</span> Policies may enforce wrong
technical solutions for some utilities proposed to the standard
library<a href="#policies-may-enforce-wrong-technical-solutions-for-some-utilities-proposed-to-the-standard-library" class="self-link"></a></h4>
<p>A major concern may be that “Policies” block specific technical
solutions from being proposed into the standard library. This is a valid
concern, and we address it by requiring a significant majority to set a
policy, and by allowing bypassing a policy (with rationale).</p>
<h3 data-number="2.2.3" id="summary"><span class="header-section-number">2.2.3</span> Summary<a href="#summary" class="self-link"></a></h3>
<p>We are aware that reaching a library-wide agreement is challenging.
However, we don’t suggest “a single rule fits all”. We suggest “a
well-defined rule can be bypassed with care”. An example of such a
policy <strong>could</strong> be:</p>
<ul>
<li>Policy A (example only, NOT proposed in this document): “Provide
both <code class="sourceCode default">.at()</code> (throwing) and
<code class="sourceCode default">operator[]</code> for every new
container for the standard library.”</li>
</ul>
<p>Assuming such a <em>hypotetical</em> policy:</p>
<ol type="1">
<li>This DOESN’T mean that container X, meant for embedded use, can’t be
suggested to the standard if it avoids implementing
<code class="sourceCode default">.at()</code>. It <strong>can</strong>
do so, by explicitly stating that it bypasses “Policy A”, due to
<em>some reasoning</em>.</li>
<li>This certainly DOESN’T mean that the rest of the library must
provide support for exceptions.</li>
</ol>
<p>We are aware that reaching a library-wide agreement (even for more
specified rules, such as the one in the example above) will cost time.
However, we believe that having such discussions once, instead of for
every new proposal, saves time in the long term (and have other
benefits, described above).</p>
<h1 data-number="3" id="impact-on-the-standard"><span class="header-section-number">3</span> Impact On the Standard<a href="#impact-on-the-standard" class="self-link"></a></h1>
<p>This proposal and the policies which will result from it are not
proposed for the C++ standard (IS).</p>
<p>However, the policies will apply to the utilities which will be
inserted into the standard.</p>
<h1 data-number="4" id="proposal"><span class="header-section-number">4</span> Proposal<a href="#proposal" class="self-link"></a></h1>
<p>We propose to set a new standing document (SD-9), which will contain
all default policies for all papers reviewd by LEWG. Authors of
<strong>new papers</strong> will have to apply these policies, unless
they provide explicit rationale for avoiding it (as described in
section: “<a href="#excluding-a-paper-from-applying-a-specific-policy">Excluding a
paper from applying a specific policy</a>”). Policies will be set using
the process described in section “<a href="#requirements-from-policy-papers-and-discussions">Requirements
From Policy Papers and Discussions</a>”, and will be added into SD-9. An
initial draft for SD-9 is included under section “<a href="#wording-for-sd-9">Wording for SD-9</a>”.</p>
<h2 data-number="4.1" id="requirements-from-policy-papers-and-discussions"><span class="header-section-number">4.1</span> Requirements From Policy Papers
and Discussions<a href="#requirements-from-policy-papers-and-discussions" class="self-link"></a></h2>
<h3 data-number="4.1.1" id="requirements-from-a-policy-paper"><span class="header-section-number">4.1.1</span> Requirements from a policy
paper<a href="#requirements-from-a-policy-paper" class="self-link"></a></h3>
<p>A policy paper is a paper for adding, changing or updating a
policy.</p>
<p>Being significant to the committee process, the paper must contain
the following:</p>
<ol type="1">
<li>A rationale.</li>
<li>A survey of the prior art of the topic, as appears in the
standard.</li>
<li>A survey of the status quo for this topic, in the wider C++
community. Preferably, this should contain the impact on different
domains and industries.</li>
<li>A clear and concise definition of the policy proposed.</li>
<li>A proposed changes to the wording of SD-9.</li>
</ol>
<p>The wording shall include a link back to the paper making the
proposal (including revision) so that it is easier to determine what was
known at the time of the change for purposes of “new information”.</p>
<h3 data-number="4.1.2" id="the-process-of-setting-a-policy"><span class="header-section-number">4.1.2</span> The process of setting a
policy<a href="#the-process-of-setting-a-policy" class="self-link"></a></h3>
<p>Since a policy has a significant impact on the standard library, we
need to make sure all interested parties have a say.</p>
<p>We propose the following process for setting a policy:</p>
<ol type="1">
<li>LEWG will announce a policy topic for discussion at least one month
prior to the mailing list deadline, to allow all the stake-holders to
publish a paper for the upcoming mailing list, and either attend or send
representatives.</li>
<li>All papers for or against a policy have to appear in the mailing
list before the meeting.</li>
<li>Passing a policy paper requires a significant majority of the
room.</li>
<li>The policy vote requires approval by an electronic poll.</li>
<li>The approved policy wording (as described in the paper) will then be
added to SD-9.</li>
</ol>
<h3 data-number="4.1.3" id="the-process-of-modifying-a-policy"><span class="header-section-number">4.1.3</span> The process of modifying a
policy<a href="#the-process-of-modifying-a-policy" class="self-link"></a></h3>
<p>We propose the following process for modifying a policy:</p>
<ol type="1">
<li>In order to schedule a meeting for re-discussing a policy, there
should be new information.</li>
<li>The rest of the process will follow the steps in section “The
process of setting a policy”.</li>
</ol>
<h3 data-number="4.1.4" id="the-process-of-removing-a-policy"><span class="header-section-number">4.1.4</span> The process of removing a
policy<a href="#the-process-of-removing-a-policy" class="self-link"></a></h3>
<p>During a discussion on modifying a policy, a need to remove a policy
may come up.</p>
<p>This should be done using the same process used for adding a
policy.</p>
<h3 data-number="4.1.5" id="excluding-a-paper-from-applying-a-specific-policy"><span class="header-section-number">4.1.5</span> Excluding a paper from
applying a specific policy<a href="#excluding-a-paper-from-applying-a-specific-policy" class="self-link"></a></h3>
<p>To address the concerns brought up in “<a href="#cons-for-setting-policies-for-the-standard-library">Cons for
setting policies for the standard library</a>”, policies should be able
to get bypassed. We believe that even if bypassed, there’s still value
in a policy, for setting the common understanding, and saving time as
described above.</p>
<p>Bypassing a policy should be done by explicitly stating the policy
bypassed (and the specific way in which it’s being bypassed, if needed),
as well as <strong>detailed technical rationale and
justifications</strong> in the paper.</p>
<p>Prior art in the field discussed can also help with providing
reasoning, but it’s the authors’ responsibility to explain why the
policy can’t be successfully applied to the utility proposed into the
standard library.</p>
<h2 data-number="4.2" id="wording-for-sd-9"><span class="header-section-number">4.2</span> Wording for SD-9<a href="#wording-for-sd-9" class="self-link"></a></h2>
<h3 class="unnumbered" id="what-are-standard-library-policies">What are
Standard Library Policies<a href="#what-are-standard-library-policies" class="self-link"></a></h3>
<p>A “policy” is any technical rule or technical guideline, which should
be followed by authors of proposals of utilities for the C++ standard
library.</p>
<p>Policies are set by Library Evolution Work Group (under
JCT1/SC22/WG21), using the process described in: <span class="citation" data-cites="P2267R1">[<a href="#ref-P2267R1" role="doc-biblioref">P2267R1</a>]</span>.</p>
<p>The following document describes the existing C++ Standard Library
Policies. Please read it carefully before writing a proposal to
LEWG.</p>
<p>As a rule, your paper should apply all the policies. The section “<a href="#excluding-a-proposal-from-applying-a-policy">Excluding a proposal
from applying a policy</a>” describes the process that should be
followed for any policy to be bypassed.</p>
<h3 class="unnumbered" id="motivation-for-standard-library-policies">Motivation for Standard
Library Policies<a href="#motivation-for-standard-library-policies" class="self-link"></a></h3>
<h4 class="unnumbered" id="pros-for-setting-policies">Pros for setting
policies:<a href="#pros-for-setting-policies" class="self-link"></a></h4>
<ol type="1">
<li>Policies create uniformity in users’ expectations from the behaviour
of different parts of the standard library</li>
<li>Policies save time for both authors and the committee</li>
<li>Policies need to be created from a shared knowledge base</li>
<li>Policies make the standardization process friendly for
newcomers</li>
</ol>
<h4 class="unnumbered" id="cons-for-setting-a-policies">Cons for setting
a policies:<a href="#cons-for-setting-a-policies" class="self-link"></a></h4>
<ol type="1">
<li>Policies may “push aside” domains which are in a minority
representation in the committee</li>
<li>Policies may enforce wrong technical solution for some utilities
proposed for the standard library</li>
</ol>
<h3 class="unnumbered" id="excluding-a-proposal-from-applying-a-policy">Excluding a proposal
from applying a policy<a href="#excluding-a-proposal-from-applying-a-policy" class="self-link"></a></h3>
<p>To address the concerns brought up above, a paper can avoid applying
a policy, as long as it contains detailed technical rationale and
justifications.</p>
<p>Prior art in the field discussed can also help with providing
reasoning, but it’s the authors’ responsibility to explain why the
policy can’t be successfully applied to the utility proposed into the
standard library.</p>
<h3 class="unnumbered" id="list-of-standard-library-policies">List of
Standard Library Policies<a href="#list-of-standard-library-policies" class="self-link"></a></h3>
<p>(TODO)</p>
<h1 data-number="5" id="acknowledgements"><span class="header-section-number">5</span> Acknowledgements<a href="#acknowledgements" class="self-link"></a></h1>
<p>Thank you to the co-authors Ben Craig and Fabio Fracassi, and to Dvir
Yitzchaki and Andrei Zissu for productive discussions.</p>
<h1 data-number="6" id="appendix-a"><span class="header-section-number">6</span> Appendix A<a href="#appendix-a" class="self-link"></a></h1>
<h2 data-number="6.1" id="policy-examples-not-proposed-in-this-document"><span class="header-section-number">6.1</span> Policy Examples (NOT proposed
in this document)<a href="#policy-examples-not-proposed-in-this-document" class="self-link"></a></h2>
<p>Examples of topics which <strong>MAY</strong> be discussed as
policies in LEWG (we DO NOT suggest any of them in this paper):</p>
<ol type="1">
<li>Mark all constructors or only single parameter constructors as
<code class="sourceCode default">explicit</code></li>
<li>Use hidden friends for ADL detection</li>
<li>Use a wide contract or a narrow contract for setting the rules of
<code class="sourceCode default">noexcept</code></li>
<li>Limit new utilities using concepts instead of type traits</li>
<li>Small headers vs. large headers</li>
<li>Member functions vs. free functions</li>
<li>Mandatory <code class="sourceCode default">[[nodiscard]]</code> on
relevant functions</li>
</ol>
<p>Note that the <span class="citation" data-cites="requirements">[<a href="#ref-requirements" role="doc-biblioref">requirements</a>]</span>
section which appears in the beginning of the standard library section
in the C++ working draft does not conflict with policies as the policies
are focused on Library API.</p>
<p>They are also not discussed in <span class="citation" data-cites="N4944">[<a href="#ref-N4944" role="doc-biblioref">N4944</a>]</span> or <span class="citation" data-cites="N4938">[<a href="#ref-N4938" role="doc-biblioref">N4938</a>]</span>.</p>
<h2 data-number="6.2" id="statistics-of-the-stadard-library"><span class="header-section-number">6.2</span> Statistics of the Stadard
Library<a href="#statistics-of-the-stadard-library" class="self-link"></a></h2>
<p>In the table below, we see the prevalence in the “<a href="https://eel.is/c++draft/#containers">Containers</a>” section of
the standard library (containers, adaptors and views), of features which
<strong>may</strong> be considered as policy candidates.</p>
<h3 data-number="6.2.1" id="disclaimers"><span class="header-section-number">6.2.1</span> Disclaimers<a href="#disclaimers" class="self-link"></a></h3>
<ul>
<li>We DO NOT suggest here to fix these specific inconsistencies (they
might as well be justified), but only to show that these inconsistencies
<strong>exist</strong> (and <strong>may</strong> be decreased by setting
Policies for <strong>future</strong> standard library utils).</li>
<li>The information was collected as an example, we don’t garentee there
are no counting errors. Authors of the relevant proposals should verify
the accuracy of the info when collecting these statistics (We will be
happy to provide the collected info).</li>
</ul>
<h3 data-number="6.2.2" id="examples-table-1"><span class="header-section-number">6.2.2</span> Examples (Table 1)<a href="#examples-table-1" class="self-link"></a></h3>
<table>
<colgroup>
<col style="width: 10%" />
<col style="width: 17%" />
<col style="width: 19%" />
<col style="width: 17%" />
<col style="width: 17%" />
<col style="width: 17%" />
</colgroup>
<thead>
<tr class="header">
<th style="text-align: left;"><div style="text-align:center">
<strong>Feature</strong>
</div></th>
<th style="text-align: center;"><div style="text-align:center">
<strong>First option</strong>
</div></th>
<th style="text-align: center;"><div style="text-align:center">
<strong>Second option</strong>
</div></th>
<th style="text-align: center;"><div style="text-align:center">
<strong>Third option</strong>
</div></th>
<th style="text-align: center;"><div style="text-align:center">
<strong>Forth option</strong>
</div></th>
<th style="text-align: center;"><div style="text-align:center">
<strong>Fifth option</strong>
</div></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"># of utils with
<code class="sourceCode default">explicit</code> CTORs</td>
<td style="text-align: center;">No explicit CTORs<br />(2)</td>
<td style="text-align: center;">Only regular explicit
CTORs<br />(12)</td>
<td style="text-align: center;">Both templated and regular explicit
CTORs<br />(7)</td>
<td style="text-align: center;">Only templated explicit
CTORs<br />(2)</td>
<td style="text-align: center;">-</td>
</tr>
<tr class="even">
<td style="text-align: left;"># of utils with conditionally
<code class="sourceCode default">explicit</code> CTORs</td>
<td style="text-align: center;">No conditionally explicit
CTORs<br />(20)</td>
<td style="text-align: center;">Both conditionally and regular explicit
CTORs<br />(1)</td>
<td style="text-align: center;">Only conditionally explicit
CTORs<br />(1)</td>
<td style="text-align: center;">Irrelevant<br />(1)</td>
<td style="text-align: center;">-</td>
</tr>
<tr class="odd">
<td style="text-align: left;">“Swap” technique</td>
<td style="text-align: center;">constexpr free function calls constexpr
member function<br />(2)</td>
<td style="text-align: center;">template free function calls class
template member function<br />(16)</td>
<td style="text-align: center;">template free function calls class
template member friend function<br />(4)</td>
<td style="text-align: center;">class template member friend function
only<br />(1)</td>
<td style="text-align: center;">Irrelevant<br />(2)</td>
</tr>
</tbody>
</table>
<p>We could consider other aspects, example for such are:</p>
<ul>
<li>Number of utils constexpr CTORs</li>
<li>Number of utils with
<code class="sourceCode default">noexcept</code> CTORs (no noexcept
CTORs / both noexcept and regular CTORs / noexcept CTORs only)</li>
<li>Error handling in containers (exception throwing only / return value
only / utilities support both / utilities with other error handling
approaches)</li>
<li>etc.</li>
</ul>
<h1 data-number="7" id="bibliography"><span class="header-section-number">7</span> References<a href="#bibliography" class="self-link"></a></h1>
<div id="refs" class="references csl-bib-body hanging-indent" role="doc-bibliography">
<div id="ref-library-design-guidelines" class="csl-entry" role="doc-biblioentry">
[library-design-guidelines] Titus Winters. 2018. Standard Library
Guidelines. <a href="https://github.com/cplusplus/LEWG/blob/archive/library-design-guidelines.md"><div class="csl-block">https://github.com/cplusplus/LEWG/blob/archive/library-design-guidelines.md</div></a>
</div>
<div id="ref-N4938" class="csl-entry" role="doc-biblioentry">
[N4938] Thomas Köppe. 2023. Working Draft, C++ Extensions for Library
Fundamentals, Version 3. <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4939.html"><div class="csl-block">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4939.html</div></a>
</div>
<div id="ref-N4944" class="csl-entry" role="doc-biblioentry">
[N4944] Thomas Köppe. 2023. Working Draft, Standard for Programming
Language C++. <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4944.pdf"><div class="csl-block">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4944.pdf</div></a>
</div>
<div id="ref-P0684R2" class="csl-entry" role="doc-biblioentry">
[P0684R2] Titus Winters. 2018. C++ Stability, Velocity, and Deployment
Plans. <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0684r2.pdf"><div class="csl-block">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0684r2.pdf</div></a>
</div>
<div id="ref-P1655R0" class="csl-entry" role="doc-biblioentry">
[P1655R0] Zach Laine. 2019. LEWG Omnibus Design Policy Paper. <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1655r0.pdf"><div class="csl-block">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1655r0.pdf</div></a>
</div>
<div id="ref-P2148R0" class="csl-entry" role="doc-biblioentry">
[P2148R0] CJ Johnson and Bryce Adelstein Lelbach. 2020. Library
Evolution Design Guidelines. <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2148r0.pdf"><div class="csl-block">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2148r0.pdf</div></a>
</div>
<div id="ref-P2267R1" class="csl-entry" role="doc-biblioentry">
[P2267R1] Inbal Levi, Ben Craig, and Fabio Fracassi. 2023. Library
Evolution Policies. <a href="https://wg21.link/P2267"><div class="csl-block">https://wg21.link/P2267</div></a>
</div>
<div id="ref-requirements" class="csl-entry" role="doc-biblioentry">
[requirements] Verious. 2023. Library-wide requirements. <a href="https://eel.is/c++draft/requirements"><div class="csl-block">https://eel.is/c++draft/requirements</div></a>
</div>
</div>
</div>
</div>
</body>
</html>
