﻿<!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="2019-06-10" />
  <title>"Throws: Nothing" should be noexcept</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%;}
      #refs p{padding-left: 32px; text-indent: -32px;}
  </style>
  <style>
a.sourceLine { display: inline-block; line-height: 1.25; }
a.sourceLine { pointer-events: none; color: inherit; text-decoration: inherit; }
a.sourceLine:empty { height: 1.2em; }
.sourceCode { overflow: visible; }
code.sourceCode { white-space: pre; position: relative; }
div.sourceCode { margin: 1em 0; }
pre.sourceCode { margin: 0; }
@media screen {
div.sourceCode { overflow: auto; }
}
@media print {
code.sourceCode { white-space: pre-wrap; }
a.sourceLine { text-indent: -1em; padding-left: 1em; }
}
pre.numberSource a.sourceLine
  { position: relative; left: -4em; }
pre.numberSource a.sourceLine::before
  { content: attr(title);
    position: relative; left: -1em; text-align: right; vertical-align: baseline;
    border: none; pointer-events: all; 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 {
a.sourceLine::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 span.va {color: #006e28}
code.diff span.st {color: #bf0303}
  </style>
  <style type="text/css">
body {
margin: 5em;
font-family: arial,sans-serif;

hyphens: auto;
line-height: 1.35;
}
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; }
a.hidden_link {
text-decoration: none;
color: inherit;
}
li {
margin-top: 0.6em;
margin-bottom: 0.6em;
}
h1 { line-height: 1; }
h2 { line-height: 1; }
h3 { line-height: 1; }
h4 { line-height: 1; }
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.self-link {
color: #3C6EB4;
text-decoration: none;
}
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; }
div.marginalizedparent {
position: relative;
left: -5em;
}
li > div.marginalizedparent { left: -7em; }
li > ul > li > div.marginalizedparent { left: -9em; }
li > ul > li > ul > li > div.marginalizedparent { left: -11em; }
li > ul > li > ul > li > ul > li > div.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; }
</style>
  <link href="data:image/vnd.microsoft.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">"Throws: Nothing" should be <code>noexcept</code></h1>

<table style="border:none;float:right">
  <tr>
    <td>Document #: </td>
    <td>P1656R0</td>
  </tr>
  <tr>
    <td>Date: </td>
    <td>2019-06-10</td>
  </tr>
  <tr>
    <td style="vertical-align:top">Project: </td>
    <td>Programming Language C++<br>
      Library Evolution Working Group<br>
    </td>
  </tr>
  <tr>
    <td style="vertical-align:top">Reply-to: </td>
    <td>
      Agustín Bergé<br>&lt;<a href="mailto:agustinberge@gmail.com" class="email">agustinberge@gmail.com</a>&gt;<br>
    </td>
  </tr>
</table>

</header>
<div style="clear:both">
    <blockquote>
        <p>“Has the C++ community considered adding <code>noexcept</code> specifications to standard-library functions that (in practice) never throw?”</p>
    </blockquote>
    <a class="self-link" href="#introduction"><h2 id="introduction">1. Introduction</h2></a>
    <p>A function that "Throws: Nothing" is a non-throwing function, and as such it ought to have a non-throwing exception specification: <code>noexcept</code>. The reason some functions continue to be specified as "Throws: Nothing" in a <code>noexcept</code> world is <em>contracts</em>; functions with preconditions are only defined for the subset of its potential inputs that satisfy them. These functions are said to have a <em>narrow contract</em>, while functions defined for all its potential inputs —that is, with no preconditions— are said to have a <em>wide contract</em>:</p>
    <ul>
        <li><p>A <em>wide contract</em> for a function or operation does not specify any undefined behavior. Such a contract has no preconditions: A function with a wide contract places no additional runtime constraints on its arguments, on any object state, nor on any external global state. Examples of functions having wide contracts would be <code>vector&lt;T&gt;::begin()</code> and <code>vector&lt;T&gt;::at(size_type)</code>.</p></li>
        <li><p>A <em>narrow contract</em> is a contract which is not wide. Narrow contracts for functions or operations result in undefined behavior when called in a manner that violates the documented contract. Such a contract specifies at least one precondition involving its arguments, object state, or some external global state, such as the initialization of a static object. Examples of functions having narrow contracts would be <code>vector&lt;T&gt;::front()</code> and <code>vector&lt;T&gt;::operator[](size_type)</code>.</p></li>
    </ul>
    <p>The <code>noexcept</code> policy followed by the standard library —first adopted with <span class="citation" data-cites="N3279">[<a href="#ref-N3279" role="doc-biblioref">N3279</a>]</span> and later revised by <span class="citation" data-cites="P0884">[<a href="#ref-P0884" role="doc-biblioref">P0884</a>]</span>— specify that a function that the LWG agree cannot throw should be marked as unconditionally <code>noexcept</code> if they have a <em>wide contract</em>. No such provision is specified for functions with a <em>narrow contract</em>, which are specified as "Throws: Nothing" instead. Making a function <code>noexcept</code> in effect partially defines the undefined nature of a narrow contract, making it impossible for an implementation to exploit it by throwing an exception.</p>
    <p>It is a common misconception that the policy supports standard library implementations that wish to diagnose contract violations by throwing exceptions. No known implementation actually wants this. The policy supports one implementation’s method of testing its contract checks: installing a throwing violation handler and expecting an exception when deliberately violating function preconditions. This is a form of negative unit testing commonly known as death testing, except that it is implemented on top of the stack unwinding mechanism required for exception support, rather than the usual process termination mode whose cost has proven to be inviable to large companies like Bloomberg.</p>
    <a class="self-link" href="#contracts-and-noexcept"><h3 id="contracts-and-noexcept">Contracts and <code>noexcept</code></h3></a>
    <p>With contracts as a language feature, C++20 introduces build levels, contract violation handlers, they are even allowed to throw to signal failure! It is almost as if they were designed to support this particular testing scenario, except it runs into the same complication it did back in C++11: <code>noexcept</code>.</p>
    <blockquote>
        <p><strong>[dcl.attr.contract.check]/6</strong> If a violation handler exits by throwing an exception and a contract is violated on a call to a function with a non-throwing exception specification, then the behavior is as if the exception escaped the function body. [<em>Note:</em> The function <code>std::terminate</code> is invoked. <em>-end note</em>] […]</p>
    </blockquote>
    <p>The missing piece would be a dedicated <em>test</em> build level, in which an exception thrown from a precondition’s violation handler (but no other) would be allowed to propagate into the immediate caller, performing regular stack unwinding in the process.</p>
    <p>This was originally proposed in <span class="citation" data-cites="N3248">[<a href="#ref-N3248" role="doc-biblioref">N3248</a>]</span>, along with the recommendation to specify functions with a <em>narrow contract</em> as <code>noexcept</code> as well, but it was ultimately rejected by EWG.</p>
    <p>Contracts do bring a change in perspective, nevertheless; the decision of exploiting the undefined nature of a narrow contract by throwing an exception shifts, from a library implementor to a library user, from a library’s test suite to any context in which it is used.</p>
    <a class="self-link" href="#motivation"><h2 id="motivation">2. Motivation</h2></a>
    <p><code>noexcept</code> is a contract, it is a guarantee for the caller that no exception will escape the function. It is one of the first contracts to be expressed in the core language, later further promoted to take part of the type system.</p>
    <p>Users expect <code>noexcept</code> contracts from the standard library, and are surprised when they find the committee is not yet ready for that level of commitment. They may suspect at first there could be some exception they have not anticipated —dynamic memory allocation is often a suspect—, or that it is simply an oversight on the part of the committee. Their suggestions to mark these "Throws: Nothing" functions as <code>noexcept</code> often turns into a stronger requirement once they learn about our policies and rationale.</p>
    <p>A conservative approach was appropriate at the 11th hour of C++0x’s standardization cycle, as there was little experience with the feature. By now implementations have matured, and users and implementors have gained experience with the feature.</p>
    <p>We should revisit our <code>noexcept</code> design policies, and adjust them as appropriate. We should make an effort to educate users if we expect them to follow our practices, or at the very least so that our practices are not misrepresented as the desire to diagnose undefined behavior via exceptions.</p>
    <p>What follows is information gathered on aspects that are invoked as reasons for adding or removing <code>noexcept</code>.</p>
    <a class="self-link" href="#diagnosing-undefined-behavior"><h3 id="diagnosing-undefined-behavior">Diagnosing Undefined Behavior</h3></a>
    <p>Putting an exception specification on a narrow contract arbitrarily limits what an implementor can do in order to respond to that violation. It partially defines what would otherwise be truly undefined behavior, as it makes throwing an exception practically impossible.</p>
    <p>A disadvantage of using exceptions for diagnostic purposes is that any evidence of the failed precondition may be destroyed as stack unwinding takes place, making the violation harder to diagnose. Furthermore, the exception might be swallowed by some user <code>catch</code> clause, or lead to termination on its way up the stack when combined with the ever more prevalent use of <code>noexcept</code> in user and library code. For these diagnosing exceptions to be useful, they need to be carefully integrated into the codebase.</p>
    <p>Much of the rejection towards the <code>noexcept</code> design policies —from regular users as well as more than a few committee members —, originates from the incorrect belief that this is the scenario the policies are meant to support.</p>
    <a class="self-link" href="#control-flow"><h3 id="control-flow">Control Flow</h3></a>
    <p>Exceptions may sometimes be used as a control flow mechanism, causing a jump to a remote <code>catch</code> clause. It can be seen as the C++ counterpart of C’s <code>setjmp</code>/<code>longjmp</code>, as it performs stack unwinding, calling destructors on its way up the stack.</p>
    <p>Examples of this use case are <code>boost::thread_interrupted</code> and pthread’s cancellation requests, as well as Bloomberg’s specific assertion test driver, for which the policy provides support. Contract violation assertions are tested by installing a throwing assertion handler, and expecting exceptions when deliberately violating the contract of the function under test.</p>
    <p>Other standard library implementors test their assertions via <em>death tests</em>, named like that because the contract violation assertions cause the process to die. (See <a href="https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#death-tests" class="uri">https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#death-tests</a>)</p>
    <p><em>libstdc++</em> tests assertions by expecting the test to fail at runtime by exiting with a non-zero status. It had been suggested that exceptions should be used in debug mode, so that test could simply check for the corresponding exception rather than termination. Such suggestion was rejected as it would have been a major inconvenience to its users. (See <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23888" class="uri">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23888</a>)</p>
    <p><em>libc++</em> tests assertions by <code>fork</code>ing the test process, and executes the undefined code in the fork while the parent waits for it to terminate with an expected result. It had experimented with a throwing debug mode for ease of testing, but that approach proved not to work, and has been removed since. Contract violations under <code>noexcept</code> functions led to the introduction of a <code>_NOEXCEPT_DEBUG</code> macro, removing <code>noexcept</code> in debug mode, which was found to be viral yet insufficient. Furthermore, the change in observable behavior for the users was undesirable. (See <a href="https://reviews.llvm.org/D59166" class="uri">https://reviews.llvm.org/D59166</a>)</p>
    <a class="self-link" href="#codegen-bloat"><h3 id="codegen-bloat">Codegen Bloat</h3></a>
    <p>For the purposes of codegen bloat, the effect of <code>noexcept</code> is twofold. On one hand, it obviates the need for stack unwinding, helping to avoid some of the cost that exceptions cause when they are not being used. The reduction in potential bloat, for both caller and callee alike, is an attractive property for those who are not using<code>-fno-exceptions</code>. On the other hand, enforcement of <code>noexcept</code> can require transforming any escaping exception into a call to <code>std::terminate</code>.</p>
    <blockquote>
        <p><strong>[except.spec]/5</strong> Whenever an exception is thrown and the search for a handler encounters the outermost block of a function with a non-throwing exception specification, the function <code>std::terminate</code> is called. […]</p>
    </blockquote>
    <p>For the purposes of codegen, let an expression be said to be <em>non-throwing</em> when no exception will be emitted from it. This includes all expressions for which the <code>noexcept</code> operator yields <code>true</code>, but also any other expression for which the implementation can determine that no exception will escape. The extent to which an expression is considered to be non-throwing depends on the implementation and the level of optimization being used, and it is a quality of implementation issue. Approx:</p>
    <ul>
        <li><p>A call to a "Throws: Nothing" function that is not marked <code>noexcept</code> yet whose definition is visible to the implementation, is usually determined to be non-throwing if its body does not contain any potentially-throwing expressions.</p></li>
        <li><p>A call to an <em>opaque</em> "Throws: Nothing" function —one whose definition is NOT visible to the implementation— that is not marked <code>noexcept</code>, such as a call to a function defined in a separate TU, or a call to a <code>virtual</code> function whose dynamic type gets resolved at runtime, is not usually determined to be non-throwing.</p></li>
    </ul>
    <p>Additionally, a function may be annotated with an implementation specific attribute as a guarantee that no exceptions escape from it, so that the implementation will assume all calls to such a function to be non-throwing. Unlike <code>noexcept</code>, this attribute form does not enforce termination. The GNU form of this attribute is <code>__attribute__((nothrow))</code>, and the MSVC form is <code>__declspec(nothrow)</code>.</p>
    <p>Furthermore, MSVC supports different exception handling modes, and in <code>/EHsc</code> mode it assumes that functions declared as <code>extern &quot;C&quot;</code> are non-throwing. Despite being non-conforming, the most commonly used exception handling mode is <code>/EHsc</code>.</p>
    <p>For exposition, consider the following snippet representing the interaction between user code and a "Throws: Nothing" library function which the implementation cannot determine to be non-throwing:</p>
    <div class="sourceCode" id="cb1">
        <pre class="sourceCode cpp"><code class="sourceCode cpp"><a class="sourceLine" id="cb1-1" title="1"><span class="co">//! system</span></a>
<a class="sourceLine" id="cb1-2" title="2"><span class="kw">extern</span> <span class="st">&quot;C&quot;</span> <span class="dt">void</span> sys<span class="op">(</span><span class="dt">void</span><span class="op">*)</span>; <span class="co">// (0)</span></a>
<a class="sourceLine" id="cb1-3" title="3"></a>
<a class="sourceLine" id="cb1-4" title="4"><span class="co">//! library</span></a>
<a class="sourceLine" id="cb1-5" title="5"><span class="kw">template</span> <span class="op">&lt;</span><span class="kw">typename</span> T<span class="op">&gt;</span></a>
<a class="sourceLine" id="cb1-6" title="6"><span class="dt">void</span> lib<span class="op">(</span>T<span class="op">*</span> ptr<span class="op">)</span> <span class="op">{</span> <span class="co">// (1)</span></a>
<a class="sourceLine" id="cb1-7" title="7">  <span class="ot">assert</span><span class="op">(</span>ptr <span class="op">!=</span> <span class="kw">nullptr</span><span class="op">)</span>; <span class="co">// Throws: Nothing</span></a>
<a class="sourceLine" id="cb1-8" title="8">  <span class="cf">return</span> sys<span class="op">(</span><span class="kw">static_cast</span><span class="op">&lt;</span><span class="dt">void</span><span class="op">*&gt;(</span>ptr<span class="op">))</span>;</a>
<a class="sourceLine" id="cb1-9" title="9"><span class="op">}</span></a>
<a class="sourceLine" id="cb1-10" title="10"></a>
<a class="sourceLine" id="cb1-11" title="11"><span class="co">//! user</span></a>
<a class="sourceLine" id="cb1-12" title="12"><span class="kw">struct</span> Dtor <span class="op">{</span> <span class="op">~</span>Dtor<span class="op">()</span>; <span class="op">}</span>;</a>
<a class="sourceLine" id="cb1-13" title="13"></a>
<a class="sourceLine" id="cb1-14" title="14"><span class="kw">static</span> <span class="dt">void</span> user<span class="op">()</span> <span class="op">{</span> <span class="co">// (2)</span></a>
<a class="sourceLine" id="cb1-15" title="15">  Dtor d;</a>
<a class="sourceLine" id="cb1-16" title="16">  <span class="co">/* ... */</span></a>
<a class="sourceLine" id="cb1-17" title="17">  lib<span class="op">(&amp;</span>d<span class="op">)</span>;</a>
<a class="sourceLine" id="cb1-18" title="18"><span class="op">}</span></a>
<a class="sourceLine" id="cb1-19" title="19"></a>
<a class="sourceLine" id="cb1-20" title="20"><span class="co">//# external linkage</span></a>
<a class="sourceLine" id="cb1-21" title="21"><span class="dt">void</span> f<span class="op">()</span> <span class="op">{</span> user<span class="op">()</span>; <span class="op">}</span> <span class="co">// (3)</span></a></code></pre>
    </div>
    <p>The cost of exception handling is reflected in the need for stack unwinding codegen for (2, 3) in the case (1) would throw, which is known not to do from the specification, but is not reflected in the implementation.</p>
    <p>Annotating any of (0) or (1) with a nothrow attribute causes identical codegen to that of building with exceptions turned off. Wrapping (1) in a user defined forwarding function that is annotated with a nothrow attribute has the same effect. For MSVC, specifying the <code>/EHsc</code> exception handling mode —rather than the conforming <code>/EHs</code> one— causes the same results.</p>
    <p>Marking (1) with a <code>noexcept</code> specification causes stack unwinding codegen to disappear, but introduces codegen for <code>std::terminate</code> enforcement. For GCC, this is directly encoded in the exception handling table as a terminate personality. For Clang and MSVC, this results in an implicit <code>catch (...)</code> handler being injected. The existence of a try-region appears to prevent MSVC from inlining said function. Further marking (2) with a <code>noexcept</code> specification has no effect in this scenario.</p>
    <p>For the user concerned about potential bloat from exception handling in contexts that make no use of exceptions, a good approach seems to be to mark user defined functions with a <code>noexcept</code> specification, and to replace all calls to "Throws: Nothing" library functions with wrappers annotated with the implementation specific nothrow attribute.</p>
    <a class="self-link" href="#noexcept-correctness"><h3 id="noexcept-correctness"><code>noexcept</code>-correctness</h3></a>
    <p>A correctness school of thought focuses on the <code>noexcept</code> operator giving an accurate answer, rather than seeing the <code>noexcept</code> specifier as a contract. Under this model, whether to mark a function depends on whether the implementation does actually throw; therefore, "Throws: Nothing" functions ought to be marked <code>noexcept</code>.</p>
    <p>Under this model, the standard specification would mark as <code>noexcept</code> every function for which the answer is independent of the implementation, and thus portable. This includes not only functions already specified as "Throws: Nothing", as well as those that are implicitly "Throws: Nothing" by the equivalent-to method of description, but also those with no explicit nor implicit "Throws" clause —e.g. <code>std::basic_string_view</code> constructors—.</p>
    <p>Functions for which a corresponding <code>std::is_nothrow_*</code> type trait exists deserve a special mention, as the adoption of such traits would suggest that an accurate answer is expected to be significant.</p>
    <a class="self-link" href="#existing-practice"><h2 id="existing-practice">3. Existing practice</h2></a>
    <p>Implementations are allowed to mark non-throwing functions as <code>noexcept</code>:</p>
    <blockquote>
        <p><strong>[res.on.exception.handling]/5</strong> An implementation may strengthen the exception specification for a non-virtual function by adding a non-throwing exception specification.</p>
    </blockquote>
    <p>Furthermore, contractual violations result in undefined behavior, giving implementors control of how to respond to those violations:</p>
    <blockquote>
        <p><strong>[res.on.required]/1</strong> Violation of any preconditions specified in a function’s <em>Requires</em>: element results in undefined behavior unless the function’s Throws: element specifies throwing an exception when the precondition is violated.</p>
        <p><strong>[res.on.required]/2</strong> Violation of any preconditions specified in a function’s <em>Expects</em>: element results in undefined behavior.</p>
    </blockquote>
    <p>Implementations mark many "Throws: Nothing" functions as <code>noexcept</code>, as well as others that simply don’t throw on their particular implementation, but not all. There does not seem to be any discernible pattern, implementors seem to be deciding on a case-by-case basis where strengthening is reasonable, with no stable criteria.</p>
    <p>The debug modes for <em>libstdc++</em> and <em>libc++</em> do not throw. Debug mode for <em>MSVC</em> does not throw as a means to diagnose violations either, but it does perform allocations which can potentially throw; no special provision is done for allocations from within <code>noexcept</code> functions, including strengthened ones, leading to termination.</p>
    <a class="self-link" href="#conclusions"><h2 id="conclusions">4. Conclusions</h2></a>
    <p>The <code>noexcept</code> specifier allows us to express a <em>contract</em> explicitly in the specification, in the actual interface code, even in the type system. Implementations are allowed to strengthen this contract, and do so.</p>
    <p>The use of <code>noexcept</code> in an implementation allows to reclaim some of the <em>non-zero cost</em> that exceptions introduce, although it is insufficient as it still leaves room for use of a nothrow attribute.</p>
    <p>We should not compromise the <em>design</em> of interfaces used by millions of users for one implementation’s preferred method of negative unit testing.</p>
    <a class="self-link" href="#proposed-policy"><h2 id="proposed-policy">5. Proposed Policy</h2></a>
    <ol type="a">
        <li><p>No library destructor should throw. They shall use the implicitly supplied (non-throwing) exception specification.</p></li>
        <li><p>Each library function having a <em>wide</em> contract (i.e., does not specify undefined behavior due to a precondition) that the LWG agree cannot throw, should be marked as unconditionally <code>noexcept</code>.</p></li>
        <li><p><span class="add" style="color: #006e28"><ins>Each library function having a <em>narrow</em> contract that the LWG agree cannot throw, when called with arguments satisfying function preconditions (and its own object state invariants), should be marked as unconditionally <span><code>noexcept</code></span>.</ins></span></p></li>
        <li><p>If a library swap function, move-constructor, or move-assignment operator is conditionally-wide (i.e. can be proven to not throw by applying the <code>noexcept</code> operator) then it should be marked as conditionally <code>noexcept</code>.</p></li>
        <li><p>If a library type has wrapping semantics to transparently provide the same behavior as the underlying type, then default constructor, copy constructor, and copy-assigment operator should be marked as conditionally <code>noexcept</code> the underlying exception specification still holds.</p></li>
        <li><p>No other function should use a conditional <code>noexcept</code> specification.</p></li>
        <li><p>Library functions designed for compatibility with "C" code (such as the atomics facility), may be marked as unconditionally <code>noexcept</code>.</p></li>
    </ol>
    <a class="self-link" href="#acknowledgements"><h2 id="acknowledgements">6. Acknowledgements</h2></a>
    <p>Alisdair Meredith and John Lakos for carefuly explaining the contents of <span class="citation" data-cites="N3248">[<a href="#ref-N3248" role="doc-biblioref">N3248</a>]</span> and <span class="citation" data-cites="N3279">[<a href="#ref-N3279" role="doc-biblioref">N3279</a>]</span> as well as the history behind them in detail.</p>
    <p>Ben Craig for patiently assisting with the codegen bloat analysis.</p>
    <p>Barry Revzin, Billy O’Neal, Chris Kennelly, Eric Fiselier, Howard Hinnant, JeanHeyd Meneide, Jonathan Wakely, Marshall Clow, Michael Park, Peter Dimov, Tim Song, Titus Winter, for discussing the subject with me.</p>
    <p>Everyone who answered my inquires on their use of <code>noexcept</code> and their view of the standard library design policies.</p>
    <a class="self-link" href="#references"><h2 id="references">References</h2></a>
    <div id="refs" role="doc-bibliography">
        <div id="ref-N3248">
            <p>
                [N3248] John Lakos. 2011. <code>noexcept</code> Prevents Library Validation. <br />
                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3248.pdf</a>
            </p>
        </div>
        <div id="ref-N3279">
            <p>
                [N3279] John Lakos. 2011. Conservative use of <code>noexcept</code> in the Library. <br />
                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf</a>
            </p>
        </div>
        <div id="ref-P0884">
            <p>
                [P0884] Nicolai Josuttis. 2018. Extending the <code>noexcept</code> Policy. <br />
                <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0884r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0884r0.pdf</a>
            </p>
        </div>
    </div>
</div>
</div>
</body>
</html>
