<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1,
shrink-to-fit=no" name="viewport">
  <title>P1604R0: The inline keyword is not in line with the design of modules.</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-left: calc(13px + 26.5rem - 50vw);
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-left: calc(40em - 50vw) !important;
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-left: 0 !important;
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
  <meta content="Bikeshed version a04b880cde96bf0ae2d14a0edcf2bcdcb631548b" name="generator">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="7e6d13f3f555dfa58121a4cfecd1083d8aaac4cd" name="document-revision">
<style>

.tony-table table {
    width:100%;
}

.tony-table th {
    text-align: center;
    padding-right:20px;
}

.tony-table  td {
    vertical-align:top;
}

.wording-add {
    background-color: #F6F9ED;
}


/* Table */
.data-table {
    border-collapse: collapse;
    font-size: 14px;
    min-width: 573px;
}
.data-table th {
    color: #5a5a5a;
}

.data-table th,
.data-table td {
    padding: 7px 17px;
}
.data-table caption {
    margin: 7px;
}

/* Table Header */
.data-table thead th {
    border-bottom: 2px solid #CCCCCC;
}

/* Table Body */
.data-table tbody td {
    color: #353535;
    border-bottom: 1px solid #dcdcdc;
    text-align: right;
}

.data-table tbody tr:last-child td {
    border: 0;
}

.data-table tbody tr:hover td {
    background-color: #f7f7f7;
    transition: all .2s;
}

/* Table Footer */
.data-table tfoot th {
    border-top: 1px solid #c7c7c7;
    text-align: right;
}

.array_row {
    outline: thin solid #008000
}

</style>
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-syntax-highlighting */

.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
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;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P1604R0<br>The inline keyword is not in line with the design of modules.</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Draft Proposal, <time class="dt-updated" datetime="2019-01-21">2019-01-21</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>Author:
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:corentin.jabot@gmail.com">Corentin Jabot</a>
     <dt>Audience:
     <dd>EWG
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <div class="p-summary" data-fill-with="abstract">
   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
   <p>The <code class="highlight"><c- kr>inline</c-></code> keywords make little sense in modules units. We, therefore, propose to change its meaning in module unit contexts.</p>
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
    <li>
     <a href="#inline-and-modules"><span class="secno">2</span> <span class="content">Inline and Modules</span></a>
     <ol class="toc">
      <li><a href="#compile-time-pessimizations"><span class="secno">2.1</span> <span class="content">Compile time pessimizations</span></a>
      <li><a href="#odr-violations"><span class="secno">2.2</span> <span class="content">ODR violations</span></a>
      <li><a href="#inlining-of-non-inline-functions"><span class="secno">2.3</span> <span class="content">Inlining of non <code class="highlight"><c- kr>inline</c-></code> functions</span></a>
     </ol>
    <li>
     <a href="#proposed-solutions"><span class="secno">3</span> <span class="content">Proposed solutions</span></a>
     <ol class="toc">
      <li><a href="#separate-the-inlinable-and-can-have-multiple-definitions-definitions-of-inline"><span class="secno">3.1</span> <span class="content">Separate the "inlinable" and "can have multiple definitions" definitions of <code class="highlight"><c- kr>inline</c-></code></span></a>
      <li><a href="#no-implicit-inline"><span class="secno">3.2</span> <span class="content">No implicit <code class="highlight"><c- kr>inline</c-></code></span></a>
      <li><a href="#discourage-vendors-to-inline-exported-functions-non-explicitly-inline"><span class="secno">3.3</span> <span class="content">Discourage vendors to <code class="highlight"><c- kr>inline</c-></code> exported functions non explicitly inline.</span></a>
     </ol>
    <li>
     <a href="#alternatives"><span class="secno">4</span> <span class="content">Alternatives</span></a>
     <ol class="toc">
      <li><a href="#introduce-an-inline-attribute-to-replace-inline-entierly"><span class="secno">4.1</span> <span class="content">Introduce an <code class="highlight"><c- p>[[</c-><c- kr>inline</c-><c- p>]]</c-></code> attribute to replace <code class="highlight"><c- kr>inline</c-></code> entierly</span></a>
      <li><a href="#should-some-entities-be-inlinable-by-default"><span class="secno">4.2</span> <span class="content">Should some entities be inlinable by default?</span></a>
     </ol>
    <li>
     <a href="#faq"><span class="secno">5</span> <span class="content">FAQ</span></a>
     <ol class="toc">
      <li><a href="#what-about-module-implementations-units-and-modules-partitions"><span class="secno">5.1</span> <span class="content">What about module implementations units and modules partitions?</span></a>
      <li><a href="#what-about-preamble-legacy-header-units-and-non-modular-code"><span class="secno">5.2</span> <span class="content">What about Preamble, Legacy Header units and Non-Modular code?</span></a>
      <li><a href="#how-does-this-compare-with-p1498"><span class="secno">5.3</span> <span class="content">How does this compare with <span>[P1498]</span>?</span></a>
      <li><a href="#wouldnt-this-create-a-dialect"><span class="secno">5.4</span> <span class="content">Wouldn’t this create a dialect?</span></a>
      <li><a href="#why-this-change-and-why-now"><span class="secno">5.5</span> <span class="content">Why this change and why now?</span></a>
      <li><a href="#if-c-did-have-modules-from-the-start-would-the-inline-keyword-exist-at-all-and-would-he-has-its-current-semantic"><span class="secno">5.6</span> <span class="content">If C++ did have modules from the start, would the inline keyword exist at all and would he has its current semantic?</span></a>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
   <p><code class="highlight"><c- kr>inline</c-></code> was intended as a hint for the compiler that performing inlining optimizations of marked functions was desirable.
However, for inlining to be possible, the definition of functions must be visible to the compiler - aka a prerequisite of inlinable functions
is to have their definition visible in the TUs in which they are called.</p>
   <p>To make function definitions visible in a non-modular world, it is customary to define them in headers.
However, headers are often included (stitched) to multiple sources files thereby forming multiple TU containing duplicated definitions of the same
functions.</p>
   <p>This would, of course, cause linkage error, and so inline gained a new semantic:</p>
   <blockquote>
    <p>An inline function or variable shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case.</p>
   </blockquote>
   <p>The inlining semantics of <code class="highlight"><c- kr>inline</c-></code> is described in this delightful normatively non-normative clause:</p>
   <blockquote>
    <p>The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism.
An implementation is not required to perform this inline substitution at the point of call;</p>
   </blockquote>
   <p>And so <code class="highlight"><c- kr>inline</c-></code> means both "This function is a candidate for inlining" and "This function might be defined multiple times".
This duality has been a constant source of confusion as developers struggle to understand what <code class="highlight"><c- kr>inline</c-></code> does and why both semantics are orthogonal yet intertwined.
A quick "C++ inline" search on the internet reveals how poorly <code class="highlight"><c- kr>inline</c-></code> is understood.</p>
   <p>Or is it?</p>
   <p>Practices such has header-only libraries make the link behavior of <code class="highlight"><c- kr>inline</c-></code> much more prevalent than the inlining hint semantic.
In such scenarios, functions are marked <code class="highlight"><c- kr>inline</c-></code> that are poor candidates for inlining.
It is also not easy to determine how much compilers rely on <code class="highlight"><c- kr>inline</c-></code> as an inlining hint <a data-link-type="biblio" href="#biblio-inline-hint">[inline-hint]</a>.</p>
   <h2 class="heading settled" data-level="2" id="inline-and-modules"><span class="secno">2. </span><span class="content">Inline and Modules</span><a class="self-link" href="#inline-and-modules"></a></h2>
    The module proposal <a data-link-type="biblio" href="#biblio-p1103r3">[P1103r3]</a> states: 
   <blockquote>
    <p>A module unit is a translation unit that forms part of a module.</p>
   </blockquote>
   <p>Specifically, this implies that module interface units are translation units, rather than text files stitched together to form translation units.</p>
   <p>This is a fundamental property of modules and one that makes them a superior alternative to non-modularized code and legacy header units.</p>
   <p>And so, non-inline symbols defined in module interface units have a guaranteed unique definition. This solves a number of ODR violation issues
and as such make code more reliable, which again is a major selling point of modules - Especially given that ODR violations are very hard or impossible to properly
diagnostic.</p>
   <p>By materializing interfaces as an actual entity, modules further make it easier to reason about code ownership, API and ABI, as each exported symbol is tied
to an interface, which has a name.</p>
   <p>So, what is the purpose of <code class="highlight"><c- kr>inline</c-></code> in module-unit context?</p>
   <p>Since modules units form translation units, the compiler has a unique place to put and find the compiled symbols of all symbols declared
in a module unit and do not need to duplicate any symbols declared in modules units.
But symbols marked <code class="highlight"><c- kr>inline</c-></code> need to be have their definition emitted in all TUs in which they are used, even in module units.</p>
   <p>This has undersirable consequences:</p>
   <h3 class="heading settled" data-level="2.1" id="compile-time-pessimizations"><span class="secno">2.1. </span><span class="content">Compile time pessimizations</span><a class="self-link" href="#compile-time-pessimizations"></a></h3>
   <p>Machine code needs to be emitted for <code class="highlight"><c- kr>inline</c-></code> functions in every translation unit in which they are used.
While arguably generating code for functions is fast, duplicating that work over a large number of TUs adds up.
Given that compilation, speed is an ever increasing issue and that modules have been branded as a mean to reduce compilation
time significantly, it would prove beneficial to reduce the amount of duplicated work a compiler has to do to compile a program.</p>
   <p>Compiling 1000 TUs calling the same simple function <code class="highlight"><c- n>f</c-></code> revealed a 10-25% difference (varying across compilers and optimizations levels)
depending on whether <code class="highlight"><c- n>f</c-></code> was marked <code class="highlight"><c- kr>inline</c-></code> or defined in a separate TU.
While gains in real code or in more thorough tests would be less pronounced, they would still be noticeable.</p>
   <p>Of course, when <code class="highlight"><c- kr>inline</c-></code> functions are actually inlined, compilation times are not impacted by whether or not a method is redefined -
inlining is desirable and does not constitute work duplication.</p>
   <p class="note" role="note"><span>Note:</span> It is sometimes beneficial for performances that a definition be emitted in all TUs using a definition rather than
in the TU it is declared. The authors understand this is an area an research, and our goal is to permit multiple implementation
strategies.</p>
   <h3 class="heading settled" data-level="2.2" id="odr-violations"><span class="secno">2.2. </span><span class="content">ODR violations</span><a class="self-link" href="#odr-violations"></a></h3>
   <p><code class="highlight"><c- kr>inline</c-></code> allows a symbol to be redefined multiple time but mandates that each definition must be identical.
However, we don’t have the tools to properly diagnostic or prevent violations of this rule, and as such <code class="highlight"><c- kr>inline</c-></code> in module interface units might be the source of ODR violations,
despite modules being branded as a tool to limit or better diagnostic such issues.</p>
   <h3 class="heading settled" data-level="2.3" id="inlining-of-non-inline-functions"><span class="secno">2.3. </span><span class="content">Inlining of non <code class="highlight"><c- kr>inline</c-></code> functions</span><a class="self-link" href="#inlining-of-non-inline-functions"></a></h3>
   <p>Because the way modules interface units are imported is implementation defined, whether the definitions defined in module interface units
are visible (such that inlining can be performed) is equally implementation-defined.
To be more precise</p>
   <ul>
    <li data-md>
     <p><code class="highlight"><c- kr>inline</c-></code> and implicitly inline definitions are always visible.</p>
    <li data-md>
     <p>Whether non-inline definitions (exported or not) can be inlined in importing TUs is implementation-defined.</p>
   </ul>
   <p>In practice, we observe that different compilers have different policies as to whether
non-inline definitions are included in binary modules interfaces.</p>
   <p>This is a confusing departure from the header-modules in which the definitions of all symbols defined in headers were visible
and therefore candidates for inlining.</p>
   <ul>
    <li data-md>
     <p>Exporting a symbol is not sufficient to make its definition portably visible across compilers</p>
    <li data-md>
     <p>Not marking a symbol inline is not sufficient to hide its definition portably visible  across compilers</p>
   </ul>
   <p>Implementers have suggested relying on Link Time Optimization to perform inlining of non-inlined symbols,
however we believe this to be an unsatisfactory workaround as LTO is usually time and resource consuming,
not universally used and not as efficient as compile-time inlining.</p>
   <h2 class="heading settled" data-level="3" id="proposed-solutions"><span class="secno">3. </span><span class="content">Proposed solutions</span><a class="self-link" href="#proposed-solutions"></a></h2>
   <h3 class="heading settled" data-level="3.1" id="separate-the-inlinable-and-can-have-multiple-definitions-definitions-of-inline"><span class="secno">3.1. </span><span class="content">Separate the "inlinable" and "can have multiple definitions" definitions of <code class="highlight"><c- kr>inline</c-></code></span><a class="self-link" href="#separate-the-inlinable-and-can-have-multiple-definitions-definitions-of-inline"></a></h3>
   <p>We suggest that, in the purview of a module unit, <code class="highlight"><c- kr>inline</c-></code> should only mean inlinable.</p>
   <p>This would allow a wider range of implementation strategies, including not re-defining a definition in every Translation Units.</p>
   <p>With this change, it would be implementation-defined whether an inline entity is redefined
in multiple TU.</p>
   <p>At the same time, the standard would allow (but not force)
currently "implicitly inline" entities to have their definition emmitted in more that one translation units</p>
   <ul>
    <li data-md>
     <p>template instantiations</p>
    <li data-md>
     <p>default and deleted class members</p>
    <li data-md>
     <p>class members defined in the class declaration</p>
    <li data-md>
     <p>implicitly declared class members</p>
    <li data-md>
     <p>constexpr functions</p>
    <li data-md>
     <p>lambda closure call operators</p>
    <li data-md>
     <p><code class="highlight"><c- k>constexpr</c-></code> functions</p>
   </ul>
   <h3 class="heading settled" data-level="3.2" id="no-implicit-inline"><span class="secno">3.2. </span><span class="content">No implicit <code class="highlight"><c- kr>inline</c-></code></span><a class="self-link" href="#no-implicit-inline"></a></h3>
   <p>In the purview of a module unit, the standard would not implicitly declare any entity as inlinable,
including any currently "implicitly <code class="highlight"><c- kr>inline</c-></code>" entity (list above).</p>
   <h3 class="heading settled" data-level="3.3" id="discourage-vendors-to-inline-exported-functions-non-explicitly-inline"><span class="secno">3.3. </span><span class="content">Discourage vendors to <code class="highlight"><c- kr>inline</c-></code> exported functions non explicitly inline.</span><a class="self-link" href="#discourage-vendors-to-inline-exported-functions-non-explicitly-inline"></a></h3>
   <p>While inlining is a QoI issue, inlining has ABI implications and it is important that it remains possible to maintain a stable ABI exposed through a module interface.</p>
   <p>As such we wish to discourage implementation to inline exported symbols.
the C++ ecosystem TR seems the right place to word such discouragement.</p>
   <h2 class="heading settled" data-level="4" id="alternatives"><span class="secno">4. </span><span class="content">Alternatives</span><a class="self-link" href="#alternatives"></a></h2>
   <h3 class="heading settled" data-level="4.1" id="introduce-an-inline-attribute-to-replace-inline-entierly"><span class="secno">4.1. </span><span class="content">Introduce an <code class="highlight"><c- p>[[</c-><c- kr>inline</c-><c- p>]]</c-></code> attribute to replace <code class="highlight"><c- kr>inline</c-></code> entierly</span><a class="self-link" href="#introduce-an-inline-attribute-to-replace-inline-entierly"></a></h3>
   <p>Because <code class="highlight"><c- kr>inline</c-></code> currently does two things that are intertwined in a too often poorly understood way,
and because the proposed changes give <code class="highlight"><c- kr>inline</c-></code> a different meaning in non-modularized code and
module unit purviews, it might be interesting to make the <code class="highlight"><c- kr>inline</c-></code> keyword ill-formed entierly
while replacing it by an <code class="highlight"><c- p>[[</c-><c- kr>inline</c-><c- p>]]</c-></code> attribute.
As inlining is purely a QoI concern, inlining is a prime candidate for the use of an attribute.
Doing so would make it clearer what <code class="highlight"><c- p>[[</c-><c- kr>inline</c-><c- p>]]</c-></code> does and would be easier to teach.</p>
   <h3 class="heading settled" data-level="4.2" id="should-some-entities-be-inlinable-by-default"><span class="secno">4.2. </span><span class="content">Should some entities be inlinable by default?</span><a class="self-link" href="#should-some-entities-be-inlinable-by-default"></a></h3>
   <p>Again, this is a QoI concern, and implementers are always free to inline any definition they desire,
but it might be useful to encourage that some entities, notably lambda closures remain implicitly inlinable.
Along with that, it might be interesting to offer a standardized mechanism to opt-out of inlining optimization
with a <code class="highlight"><c- p>[[</c-><c- n>noinline</c-><c- p>]]</c-></code> attribute - which would standardize an existing practice in MSVC (<code class="highlight"><c- kr>__declspec</c-><c- p>(</c-><c- n>noinline</c-><c- p>)</c-></code>) and GCC (<code class="highlight"><c- n>__attribute__</c-><c- p>((</c-><c- n>noinline</c-><c- p>))</c-></code>)</p>
   <h2 class="heading settled" data-level="5" id="faq"><span class="secno">5. </span><span class="content">FAQ</span><a class="self-link" href="#faq"></a></h2>
   <h3 class="heading settled" data-level="5.1" id="what-about-module-implementations-units-and-modules-partitions"><span class="secno">5.1. </span><span class="content">What about module implementations units and modules partitions?</span><a class="self-link" href="#what-about-module-implementations-units-and-modules-partitions"></a></h3>
   <p>All modules units should have the same specification when it comes to inline (or lack thereof), and definition visibility.</p>
   <h3 class="heading settled" data-level="5.2" id="what-about-preamble-legacy-header-units-and-non-modular-code"><span class="secno">5.2. </span><span class="content">What about Preamble, Legacy Header units and Non-Modular code?</span><a class="self-link" href="#what-about-preamble-legacy-header-units-and-non-modular-code"></a></h3>
   <p>For backward compatibility reasons, we do not propose to change the semantics of inline, implicitly inline or non-inline symbols in these contexts.</p>
   <h3 class="heading settled" data-level="5.3" id="how-does-this-compare-with-p1498"><span class="secno">5.3. </span><span class="content">How does this compare with <a data-link-type="biblio" href="#biblio-p1498">[P1498]</a>?</span><a class="self-link" href="#how-does-this-compare-with-p1498"></a></h3>
   <p><a data-link-type="biblio" href="#biblio-p1498">[P1498]</a> propose to deprecate <code class="highlight"><c- kr>inline</c-></code> in implementation units as well as for non-exported symbols.</p>
   <p>Furthermore, <a data-link-type="biblio" href="#biblio-p1498">[P1498]</a> proposes changes as to what methods can be declared <code class="highlight"><c- kr>inline</c-></code> and be inlined.
With this proposal, the compiler can decide automatically when a method cannot be inlined ( ie when it calls a symbol with module-local linkage),
rather than putting that responsibility on users.</p>
   <h3 class="heading settled" data-level="5.4" id="wouldnt-this-create-a-dialect"><span class="secno">5.4. </span><span class="content">Wouldn’t this create a dialect?</span><a class="self-link" href="#wouldnt-this-create-a-dialect"></a></h3>
   <p>No more than <code class="highlight"><c- k>export</c-></code>, which is only valid in module units, does.</p>
   <h3 class="heading settled" data-level="5.5" id="why-this-change-and-why-now"><span class="secno">5.5. </span><span class="content">Why this change and why now?</span><a class="self-link" href="#why-this-change-and-why-now"></a></h3>
   <p>Modules are a profound change to the way people will compile C++ code and it will transform the ecosystem.
It is important to make sure Modules offer the right semantics now and for the next few decades as it will certainly prove impossible
to reasonably do these sort of changes post of C++20.</p>
   <p>And while modules offer a better compilation model, they do not get rid of artifacts like <code class="highlight"><c- kr>inline</c-></code>, which were the product of the textual inclusion
model of <code class="highlight"><c- cp>#include</c-></code> directives.
The multiplication of closely-related but not identical concepts, a wide range of implementation-specific behavior and the loaded history of <code class="highlight"><c- kr>inline</c-></code> makes offering a stable API with clear boundary more challenging than it needs to be.</p>
   <h3 class="heading settled" data-level="5.6" id="if-c-did-have-modules-from-the-start-would-the-inline-keyword-exist-at-all-and-would-he-has-its-current-semantic"><span class="secno">5.6. </span><span class="content">If C++ did have modules from the start, would the inline keyword exist at all and would he has its current semantic?</span><a class="self-link" href="#if-c-did-have-modules-from-the-start-would-the-inline-keyword-exist-at-all-and-would-he-has-its-current-semantic"></a></h3>
   <p>;)</p>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-inline-hint">[INLINE-HINT]
   <dd>Simon Brand. <a href="https://blog.tartanllama.xyz/inline-hints/">Do compilers take inline as a hint?</a>. URL: <a href="https://blog.tartanllama.xyz/inline-hints/">https://blog.tartanllama.xyz/inline-hints/</a>
   <dt id="biblio-p1103r3">[P1103r3]
   <dd><a href="https://wg21.link/p1103r3">P1103R3 Merging modules</a>. URL: <a href="https://wg21.link/p1103r3">https://wg21.link/p1103r3</a>
   <dt id="biblio-p1498">[P1498]
   <dd>Chandler Carruth; Nathan Sidwell; Richard Smith. <a href="http://wg21.link/p1498">Constrained Internal Linkage for Modules</a>. URL: <a href="http://wg21.link/p1498">http://wg21.link/p1498</a>
  </dl>