<!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>p0900r0: An Ontology for Properties of &lt;code>mdspan&lt;/code></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 li { font-size:   85%;    }

	.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 li li li .secno {
		font-size: 85%;
	}
	.toc > li li li li li .secno {
		font-size: 100%;
	}

	: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; }
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) :not(li) > .toc              { margin-left:  4rem; }
		body:not(.toc-inline) .toc .secno                  { margin-left: -4rem; }
		body:not(.toc-inline) .toc > li li li              { margin-left:  1rem; }
		body:not(.toc-inline) .toc > li li li .secno       { margin-left: -5rem; }
		body:not(.toc-inline) .toc > li li li li .secno    { margin-left: -6rem; }
		body:not(.toc-inline) .toc > li li li li li .secno { margin-left: -7rem; }
	}
	body.toc-sidebar #toc :not(li) > .toc              { margin-left:  4rem; }
	body.toc-sidebar #toc .toc .secno                  { margin-left: -4rem; }
	body.toc-sidebar #toc .toc > li li li              { margin-left:  1rem; }
	body.toc-sidebar #toc .toc > li li li .secno       { margin-left: -5rem; }
	body.toc-sidebar #toc .toc > li li li li .secno    { margin-left: -6rem; }
	body.toc-sidebar #toc .toc > li li li li li .secno { margin-left: -7rem; }

	.toc li {
		clear: both;
	}


/** 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>
<style type="text/css">
    table, th, td {
      border: 1px solid black;
      border-collapse: collapse;
      vertical-align: top;
    }
    th, td {
      border-left: none;
      border-right: none;
      padding: 0px 10px;
    }
    th {
      text-align: center;
    }
  </style>
  <meta content="Bikeshed version 166744eb86a34dbc5493268ea410dc65275aa964" name="generator">
  <link href="https://kokkos.github.io/array_ref/proposals/P0900.html" rel="canonical">
<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; }
.highlight .c { color: #708090 } /* Comment */
.highlight .k { color: #990055 } /* Keyword */
.highlight .l { color: #000000 } /* Literal */
.highlight .n { color: #0077aa } /* Name */
.highlight .o { color: #999999 } /* Operator */
.highlight .p { color: #999999 } /* Punctuation */
.highlight .cm { color: #708090 } /* Comment.Multiline */
.highlight .cp { color: #708090 } /* Comment.Preproc */
.highlight .c1 { color: #708090 } /* Comment.Single */
.highlight .cs { color: #708090 } /* Comment.Special */
.highlight .kc { color: #990055 } /* Keyword.Constant */
.highlight .kd { color: #990055 } /* Keyword.Declaration */
.highlight .kn { color: #990055 } /* Keyword.Namespace */
.highlight .kp { color: #990055 } /* Keyword.Pseudo */
.highlight .kr { color: #990055 } /* Keyword.Reserved */
.highlight .kt { color: #990055 } /* Keyword.Type */
.highlight .ld { color: #000000 } /* Literal.Date */
.highlight .m { color: #000000 } /* Literal.Number */
.highlight .s { color: #a67f59 } /* Literal.String */
.highlight .na { color: #0077aa } /* Name.Attribute */
.highlight .nc { color: #0077aa } /* Name.Class */
.highlight .no { color: #0077aa } /* Name.Constant */
.highlight .nd { color: #0077aa } /* Name.Decorator */
.highlight .ni { color: #0077aa } /* Name.Entity */
.highlight .ne { color: #0077aa } /* Name.Exception */
.highlight .nf { color: #0077aa } /* Name.Function */
.highlight .nl { color: #0077aa } /* Name.Label */
.highlight .nn { color: #0077aa } /* Name.Namespace */
.highlight .py { color: #0077aa } /* Name.Property */
.highlight .nt { color: #669900 } /* Name.Tag */
.highlight .nv { color: #222222 } /* Name.Variable */
.highlight .ow { color: #999999 } /* Operator.Word */
.highlight .mb { color: #000000 } /* Literal.Number.Bin */
.highlight .mf { color: #000000 } /* Literal.Number.Float */
.highlight .mh { color: #000000 } /* Literal.Number.Hex */
.highlight .mi { color: #000000 } /* Literal.Number.Integer */
.highlight .mo { color: #000000 } /* Literal.Number.Oct */
.highlight .sb { color: #a67f59 } /* Literal.String.Backtick */
.highlight .sc { color: #a67f59 } /* Literal.String.Char */
.highlight .sd { color: #a67f59 } /* Literal.String.Doc */
.highlight .s2 { color: #a67f59 } /* Literal.String.Double */
.highlight .se { color: #a67f59 } /* Literal.String.Escape */
.highlight .sh { color: #a67f59 } /* Literal.String.Heredoc */
.highlight .si { color: #a67f59 } /* Literal.String.Interpol */
.highlight .sx { color: #a67f59 } /* Literal.String.Other */
.highlight .sr { color: #a67f59 } /* Literal.String.Regex */
.highlight .s1 { color: #a67f59 } /* Literal.String.Single */
.highlight .ss { color: #a67f59 } /* Literal.String.Symbol */
.highlight .vc { color: #0077aa } /* Name.Variable.Class */
.highlight .vg { color: #0077aa } /* Name.Variable.Global */
.highlight .vi { color: #0077aa } /* Name.Variable.Instance */
.highlight .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">p0900r0<br>An Ontology for Properties of <code class="highlight"><span class="n">mdspan</span></code></h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2018-02-12">12 February 2018</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="https://kokkos.github.io/array_ref/proposals/P0900.html">https://kokkos.github.io/array_ref/proposals/P0900.html</a>
     <dt>Author:
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:dshollm@sandia.gov">David S. Hollman</a>
     <dt>Audience:
     <dd>LEWG
     <dt>Project:
     <dd>ISO JTC1/SC22/WG21: 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>This paper is an initial exploration of approaches for the

general specification of a properties customization point;
such as proposed for mdspan <a data-link-type="biblio" href="#biblio-p0009r4">[P0009r4]</a>, span <a data-link-type="biblio" href="#biblio-p0546r1">[P0546r1]</a>,
and other proposals.
Considerations and constraints on the interaction
between disparate property customizations are examined.</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="#background-and-motivation"><span class="secno">1</span> <span class="content">Background and Motivation</span></a>
    <li>
     <a href="#design-principles-and-decisions"><span class="secno">2</span> <span class="content">Design Principles and Decisions</span></a>
     <ol class="toc">
      <li><a href="#orthogonality"><span class="secno">2.1</span> <span class="content">Orthogonality</span></a>
      <li><a href="#property-modes"><span class="secno">2.2</span> <span class="content">Property Modes</span></a>
      <li><a href="#convertibility"><span class="secno">2.3</span> <span class="content">Convertibility</span></a>
      <li><a href="#on-the-importance-of-api-invariance"><span class="secno">2.4</span> <span class="content">On the Importance of API Invariance</span></a>
      <li><a href="#gencon"><span class="secno">2.5</span> <span class="content">On Transmission into Generic Contexts</span></a>
     </ol>
    <li>
     <a href="#proposed-solution-property-traits"><span class="secno">3</span> <span class="content">Proposed Solution: Property Traits</span></a>
     <ol class="toc">
      <li>
       <a href="#traits-for-member-types"><span class="secno">3.1</span> <span class="content">Traits for Member Types</span></a>
       <ol class="toc">
        <li><a href="#on-order-dependence-and-order-invariance"><span class="secno">3.1.1</span> <span class="content">On order dependence and order invariance</span></a>
        <li><a href="#altconf"><span class="secno">3.1.2</span> <span class="content">Alternative means of resolving conflicts</span></a>
       </ol>
      <li><a href="#data-access-hooks"><span class="secno">3.2</span> <span class="content">Data Access Hooks</span></a>
      <li><a href="#layout-related-traits-and-hooks-for-mdspan-only"><span class="secno">3.3</span> <span class="content">Layout-Related Traits and Hooks for <code class="highlight"><span class="n">mdspan</span></code> Only</span></a>
      <li><a href="#traits-for-propagation-into-or-through-generic-contexts"><span class="secno">3.4</span> <span class="content">Traits for Propagation into or through Generic Contexts</span></a>
      <li><a href="#traits-for-expression-of-convertibility"><span class="secno">3.5</span> <span class="content">Traits for Expression of Convertibility</span></a>
      <li><a href="#other-potential-traits-and-hooks"><span class="secno">3.6</span> <span class="content">Other Potential Traits and Hooks</span></a>
     </ol>
    <li><a href="#open-questions-and-straw-polls"><span class="secno">4</span> <span class="content">Open Questions and Straw Polls</span></a>
    <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="background-and-motivation"><span class="secno">1. </span><span class="content">Background and Motivation</span><a class="self-link" href="#background-and-motivation"></a></h2>
   <p><a data-link-type="biblio" href="#biblio-p0009r4">[P0009r4]</a> proposes the <code class="highlight"><span class="n">mdspan</span></code> class template for viewing contiguous spans
of objects through a multidimensional index space. That paper also proposes
that the <code class="highlight"><span class="n">mdspan</span></code> class template accept <code class="highlight"><span class="n">Properties</span><span class="p">...</span></code> template parameters as
an extensible set of options for multi-index mapping and memory access:</p>
   <blockquote>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
  <span class="n">template</span><span class="o">&lt;</span> <span class="kr">typename</span> <span class="n">DataType</span> <span class="p">,</span> <span class="kr">typename</span> <span class="p">...</span> <span class="n">Properties</span> <span class="o">></span>
  <span class="n">class</span> <span class="n">mdspan</span> <span class="p">;</span>
<span class="p">}}</span>
</pre>
   </blockquote>
   <p><a data-link-type="biblio" href="#biblio-p0546r1">[P0546r1]</a> proposes that <code class="highlight"><span class="n">span</span></code> should also accept a similar set of
properties. For brevity, we will herein refer to the customization point
expressed via the <code class="highlight"><span class="n">Properties</span><span class="p">...</span></code> template parameter(s) of <code class="highlight"><span class="n">mdspan</span></code> (and,
pending <a data-link-type="biblio" href="#biblio-p0546r1">[P0546r1]</a>, <code class="highlight"><span class="n">span</span></code>) as <em>properties</em>. LEWG recommended that <a data-link-type="biblio" href="#biblio-p0019r5">[P0019r5]</a> should be redone as a property (on <code class="highlight"><span class="n">span</span></code>, though it would
probably also apply to <code class="highlight"><span class="n">mdspan</span></code>), and P0860 does this. P0856 also explores the
idea of such a property for expressing ISO-C <code class="highlight"><span class="k">restrict</span></code>-like semantics. <a data-link-type="biblio" href="#biblio-p0367r0">[P0367r0]</a> also proposed a number of properties in a more general
context, but the content is relevant to <code class="highlight"><span class="n">span</span></code> and <code class="highlight"><span class="n">mdspan</span></code> properties as
proposed here.</p>
   <p>We now formally explore the design of the proposed <em>properties</em> customization point.
In particular, the referenced papers propose a properties extension point,
define several need useful properties, and allow the application of
multiple properties to the same type.
Thus the design for how multiple properties may interact must be defined;
for example,</p>
   <ul>
    <li data-md="">
     <p>What sets of properties are allowed to be given together?</p>
     <ul>
      <li data-md="">
       <p>Does the addition of a property require the developer to define the set
of properties with which it is compatible? How do we prevent exponential
explosion of work from this requirement?</p>
     </ul>
    <li data-md="">
     <p>What does it <em>mean</em> when multiple properties are given together?</p>
     <ul>
      <li data-md="">
       <p>Again, does the addition of a property require the developer to define
the set of behaviors when combined with all other sets of properties? How
do we prevent exponential explosion of work from this requirement?</p>
     </ul>
    <li data-md="">
     <p>Are the behaviors of a <code class="highlight"><span class="n">span</span></code> or <code class="highlight"><span class="n">mdspan</span></code> dependent on the order of the
properties given? If so, what is the meaning of the order?</p>
   </ul>
   <p>We try to address these questions and other related issues by sketching an
ontology for <code class="highlight"><span class="n">mdspan</span></code> (and <code class="highlight"><span class="n">span</span></code>) properties herein.</p>
   <h2 class="heading settled" data-level="2" id="design-principles-and-decisions"><span class="secno">2. </span><span class="content">Design Principles and Decisions</span><a class="self-link" href="#design-principles-and-decisions"></a></h2>
   <p>What follows is a set of overarching principles for the design of the
property customization points. These principles suggest a set of restrictions
to the set of features implementable via the customization point, and an
exploration of the viability of these restrictions follows, particularly in the
context of the properties proposed (or suggested) thus far in other
papers.</p>
   <h3 class="heading settled" data-level="2.1" id="orthogonality"><span class="secno">2.1. </span><span class="content">Orthogonality</span><a class="self-link" href="#orthogonality"></a></h3>
   <p>The issue of exponential explosion for property compatibility specification
work is so dire (particularly with respect to vendor-supplied or user-supplied
extensions) that we suggest taking extreme measures. Thus, we propose that <strong>all</strong> properties should be allowed with all other properties,
and that any property that cannot tolerate this level of compatibility
should <em>not</em> use this customization point but should be implemented via some
other mechanism. The implications of this constraint are explored below, and a
mechanism for implementing and enforcing this constraint is also proposed
herein. Some potential for nuance within this restriction is also discussed
below.</p>
   <p>A corrollary to this principle is that the behavior and attributes of an <code class="highlight"><span class="n">mdspan</span></code> under a set of properties should be expressible as a
well-defined combination of the behaviors or attributes of the <code class="highlight"><span class="n">mdspan</span></code> under
each of those properties individually.  For instance, the <code class="highlight"><span class="k">noexcept</span></code> specifier
for <code class="highlight"><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">>::</span><span class="k">operator</span><span class="p">[](</span><span class="n">index_type</span><span class="p">)</span></code> should be expressible as:</p>
<pre class="language-c++ highlight"><span class="n">noexcept</span><span class="p">(</span><span class="n">conjunction_v</span><span class="o">&lt;</span>
  <span class="n">boolean_constant</span><span class="o">&lt;</span><span class="n">noexcept</span><span class="p">(</span><span class="n">declval</span><span class="o">&lt;</span><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Properties</span><span class="o">>></span><span class="p">()[</span><span class="n">std</span><span class="o">::</span><span class="n">declval</span><span class="o">&lt;</span><span class="n">index_type</span><span class="o">></span><span class="p">()])</span><span class="o">></span><span class="p">...</span>
<span class="o">></span><span class="p">)</span>
</pre>
   <p>Similar combination should be possible for behaviors via the specification of
hooks in a traits-like interface, as explored below.</p>
   <h3 class="heading settled" data-level="2.2" id="property-modes"><span class="secno">2.2. </span><span class="content">Property Modes</span><a class="self-link" href="#property-modes"></a></h3>
   <p>It is important to distinguish between property "types" and their
"values". For instance, <a data-link-type="biblio" href="#biblio-p0367r0">[P0367r0]</a> proposes a rich set of read/write access
qualifiers, including the expected <code class="highlight"><span class="n">read</span></code>, <code class="highlight"><span class="n">write</span></code>, and <code class="highlight"><span class="n">read_write</span></code>, but also
including more specialized "values" like <code class="highlight"><span class="n">discard_read</span></code> and <code class="highlight"><span class="n">discard_write</span></code>. It
is clear that these "values" are meant to be mutually exclusive; that is, it
would be nonsensical to have an <code class="highlight"><span class="n">mdspan</span></code> with both <code class="highlight"><span class="n">write</span></code> and <code class="highlight"><span class="n">read_write</span></code>. If
a flat model were used for the property customization point, this
nonsensical mutual exclusivity would violate the orthogonality design principle
above. However, if we instead view these as different "modes" (or "values") of
a single "property", orthogonality can be preserved while still providing the
mutual exclusivity needed to properly express this property. In this example, <code class="highlight"><span class="n">read</span></code>, <code class="highlight"><span class="n">write</span></code>, etc., would be "values" of a property named something like <code class="highlight"><span class="n">access_mode</span></code>. To avoid confusion with the loaded terms "type" and "value" that
have other meanings in C++, we will use the term "property" to refer to the
group of mutually exclusive property "values", and "property mode" to refer to
the "value" of that property. Note that most properties (at least of those
proposed thus far) will have a mode type that is merely a boolean, with their
mode indicated by their presence or abscence in the <code class="highlight"><span class="n">Properties</span><span class="p">...</span></code> parameter
pack. Another example of a non-boolean modal property is the layout property
proposed in <a data-link-type="biblio" href="#biblio-p0009r4">[P0009r4]</a>.</p>
   <h3 class="heading settled" data-level="2.3" id="convertibility"><span class="secno">2.3. </span><span class="content">Convertibility</span><a class="self-link" href="#convertibility"></a></h3>
   <p>A follow-on to the orthogonality design decision is that of convertibility (via
construction or assignment).  In similar interest of avoiding exponential
explosion of pairwise convertibility specification and implementation, it makes
sense to impose the constraint that an <code class="highlight"><span class="n">mdspan</span></code> with <em>any</em> set of 
properties is always convertible to an <code class="highlight"><span class="n">mdspan</span></code> with any other set of
properties (and likewise for <code class="highlight"><span class="n">span</span></code>).  A slight nuance that could be added to
this constraint is to allow properties to forbid interconversion between
different <em>modes</em> within the same property.  For instance, with the access mode
property proposed in <a data-link-type="biblio" href="#biblio-p0367r0">[P0367r0]</a>, if the <code class="highlight"><span class="n">read</span></code> mode of that property is
specified to mean that only reads will be done from the data in the <code class="highlight"><span class="n">mdspan</span></code> or
objects derived from it, then it is a clear violation of the contract to convert
such an <code class="highlight"><span class="n">mdspan</span></code> into one with the <code class="highlight"><span class="n">write</span></code> mode of that property.  It is not
unreasonable to allow this prohibition to be made within the type system, since
the specification complexity is always linear in the number of modes of the
property, and since the modes of a given property are not subject to the same
extensibility constraints as properties themselves.</p>
   <h3 class="heading settled" data-level="2.4" id="on-the-importance-of-api-invariance"><span class="secno">2.4. </span><span class="content">On the Importance of API Invariance</span><a class="self-link" href="#on-the-importance-of-api-invariance"></a></h3>
   <p>In the design of many customization points analogous to the properties
proposed herein, invariance of the API for members of the resulting class
template instantiation is critical to its usefulness in a generic context. For
example, the invariance of the <code class="highlight"><span class="n">vector</span></code> API with respect to the <code class="highlight"><span class="n">Allocator</span></code> template parameter customization point makes the following generic code viable:</p>
<pre class="highlight"><span class="k">template</span> <span class="o">&lt;</span><span class="k">typename</span> <span class="n">T</span><span class="p">,</span> <span class="k">typename</span> <span class="n">Allocator</span><span class="o">></span>
<span class="k">auto</span> <span class="n">copy_odd_values</span><span class="p">(</span><span class="k">const</span> <span class="n">vector</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Allocator</span><span class="o">>&amp;</span> <span class="n">v</span><span class="p">)</span> <span class="p">{</span>
    <span class="n">vector</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Allocator</span><span class="o">></span> <span class="n">ret</span><span class="p">;</span>
    <span class="k">auto</span> <span class="n">is_odd</span> <span class="o">=</span> <span class="p">[](</span><span class="n">T</span> <span class="k">const</span><span class="o">&amp;</span> <span class="n">i</span><span class="p">)</span> <span class="p">{</span> <span class="k">return</span> <span class="n">i</span> <span class="o">%</span> <span class="mi">2</span> <span class="o">!=</span> <span class="mi">0</span><span class="p">;</span> <span class="p">};</span>
    <span class="n">std</span><span class="o">::</span><span class="n">copy_if</span><span class="p">(</span><span class="n">v</span><span class="p">.</span><span class="n">begin</span><span class="p">(),</span> <span class="n">v</span><span class="p">.</span><span class="n">end</span><span class="p">(),</span> <span class="n">std</span><span class="o">::</span><span class="n">back_insert_iterator</span><span class="p">(</span><span class="n">ret</span><span class="p">),</span> <span class="n">is_odd</span><span class="p">);</span>
    <span class="k">return</span> <span class="n">ret</span><span class="p">;</span>
<span class="p">}</span>
</pre>
   <p>In the context of properties for <code class="highlight"><span class="n">span</span></code> and <code class="highlight"><span class="n">mdspan</span></code>, this invariance is
actually not quite as critical for several important reasons. Most importantly,
both <code class="highlight"><span class="n">span</span></code> and <code class="highlight"><span class="n">mdspan</span></code> are intended to be passed by value. Thus, there is less
need to template on the <code class="highlight"><span class="n">Properties</span><span class="p">...</span></code> template parameters, for example in order
to avoid spurious copies to <code class="highlight"><span class="k">const</span></code> reference parameters. In fact, some
properties represent a contract that would be dangerous to transmit into a
generic context, as is the case with <code class="highlight"><span class="n">restrict_access</span></code> (proposed in P0856).
In such cases, it actually makes more sense to eschew support for a generic
properties variadic template parameter in favor of specific enumeration of the
properties known to be supported by the generic function.  Many
compiler-specific properties are likely to also represent similar sorts
of contracts.</p>
   <h3 class="heading settled" data-level="2.5" id="gencon"><span class="secno">2.5. </span><span class="content">On Transmission into Generic Contexts</span><a class="self-link" href="#gencon"></a></h3>
   <p>Unfortunately, for other proposed properties, transmission into and through a
generic context <em>is</em> desirable.  The <code class="highlight"><span class="n">bounds_checking</span></code> and <code class="highlight"><span class="n">layout</span></code> properties
suggested in <a data-link-type="biblio" href="#biblio-p0009r4">[P0009r4]</a> should be transmitted without issue into most generic
contexts.  Without loss of extensibility (i.e., without doing things like
explicitly listing the properties that may be transmitted, which precludes the
use of vendor-specific or user-specific properties), it is not easy to write
code that is generic with respect to some properties but not others.  A
potential solution for this is explored below.</p>
   <h2 class="heading settled" data-level="3" id="proposed-solution-property-traits"><span class="secno">3. </span><span class="content">Proposed Solution: Property Traits</span><a class="self-link" href="#proposed-solution-property-traits"></a></h2>
   <p>One way to implement many of the design constraints expressed above is to
specify a mechanism for the application of properties to a <code class="highlight"><span class="n">span</span></code> or <code class="highlight"><span class="n">mdspan</span></code> that maintains adherence to these design principles through its action.  As
such, we propose a set of property traits via which most of the aspects
of most of the properties proposed thus far can be expressed.  (Those that
express contracts or hints to compilers and optimizers obviously cannot be fully
specified in this way, but even in those cases some of these traits may be
relevant.)  The traits in this section are expressed at namespace scope, in
keeping with newer interface proposals such as the one in <a data-link-type="biblio" href="#biblio-p0443r3">[P0443R3]</a>, rather than
at class scope (as is the case with <code class="highlight"><span class="n">allocator_traits</span></code>), but they could easily
be refactored to a different form based on feedback.  The set of traits proposed
here is not intended to be exhaustive; rather it is intended to be sufficient to
implement the properties previously proposed or suggested and most properties
foreseeable based on that experience.</p>
   <h3 class="heading settled" data-level="3.1" id="traits-for-member-types"><span class="secno">3.1. </span><span class="content">Traits for Member Types</span><a class="self-link" href="#traits-for-member-types"></a></h3>
   <p>There are two possible approaches to resolving conflicts between
properties attempting to modify the same member type. The first approach is to
apply the type trait to each property in a nested manner, using the order the
properties are given in the <code class="highlight"><span class="n">Properties</span><span class="p">...</span></code> list (though the best practice
should be that the result of this operation should be invariant with respect to
order).  For example, <code class="highlight"><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">>::</span><span class="n">element_type</span></code> would be defined
in terms of a recursive application of the following customization point:</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">element_type</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">element_type_t</span> <span class="o">=</span> <span class="kr">typename</span> <span class="n">element_type</span><span class="o">&lt;</span><span class="n">SpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">type</span><span class="p">;</span>

<span class="p">}}}</span>
</pre>
   <p>where <code class="highlight"><span class="n">SpanLike</span></code> is a <code class="highlight"><span class="n">span</span></code> or <code class="highlight"><span class="n">mdspan</span></code> with all properties preceding <code class="highlight"><span class="n">Property</span></code> in the <code class="highlight"><span class="n">Properties</span><span class="p">...</span></code> list.  For clarity, here is a possible
implementation of the <code class="highlight"><span class="n">element_type</span></code> member type of <code class="highlight"><span class="n">mdspan</span></code>:</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">DataType</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties</span><span class="o">></span>
<span class="n">class</span> <span class="n">mdspan</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">DataType</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties</span><span class="o">></span>
<span class="n">class</span> <span class="n">mdspan</span> <span class="p">{</span>
<span class="nl">public</span><span class="p">:</span>
  <span class="n">using</span> <span class="n">element_type</span> <span class="o">=</span> 
    <span class="n">properties</span><span class="o">::</span><span class="n">element_type_t</span><span class="o">&lt;</span><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">DataType</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">></span><span class="p">,</span> <span class="n">Property</span><span class="o">>></span><span class="p">;</span>
<span class="p">};</span>

<span class="c1">// Base case is the mdspan without any properties:</span>
<span class="c1"></span><span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">DataType</span><span class="o">></span>
<span class="n">class</span> <span class="n">mdspan</span> <span class="p">{</span>
<span class="nl">public</span><span class="p">:</span>
  <span class="n">using</span> <span class="n">element_type</span> <span class="o">=</span> <span class="n">remove_all_extents_t</span><span class="o">&lt;</span><span class="n">DataType</span><span class="o">></span><span class="p">;</span>  <span class="c1">// as in P0009r4</span>
<span class="c1"></span>  <span class="cm">/* ... */</span>
<span class="p">};</span>

<span class="p">}}</span>
</pre>
   <p>and the default, unspecialized implementation of the customization point for <code class="highlight"><span class="n">element_type</span></code> would be:</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">element_type</span> <span class="p">{</span> <span class="n">using</span> <span class="n">type</span> <span class="o">=</span> <span class="kr">typename</span> <span class="n">SpanLike</span><span class="o">::</span><span class="n">element_type</span><span class="p">;</span> <span class="p">};</span>

<span class="p">}}}</span>
</pre>
   <p>The rest of the element types would have similar customization points:</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">value_type</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">value_type_t</span> <span class="o">=</span> <span class="n">class</span> <span class="n">value_type</span><span class="o">&lt;</span><span class="n">SpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">type</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">index_type</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">index_type_t</span> <span class="o">=</span> <span class="n">class</span> <span class="n">index_type</span><span class="o">&lt;</span><span class="n">SpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">type</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">difference_type</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">difference_type_t</span> <span class="o">=</span> <span class="n">class</span> <span class="n">difference_type</span><span class="o">&lt;</span><span class="n">SpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">type</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">pointer</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">pointer_t</span> <span class="o">=</span> <span class="n">class</span> <span class="n">pointer</span><span class="o">&lt;</span><span class="n">SpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">type</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">reference</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">reference_t</span> <span class="o">=</span> <span class="n">class</span> <span class="n">reference</span><span class="o">&lt;</span><span class="n">SpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">type</span><span class="p">;</span>

<span class="p">}}}</span>
</pre>
   <h4 class="heading settled" data-level="3.1.1" id="on-order-dependence-and-order-invariance"><span class="secno">3.1.1. </span><span class="content">On order dependence and order invariance</span><a class="self-link" href="#on-order-dependence-and-order-invariance"></a></h4>
   <p>This approach has the disadvantage of imposing a theoretical order dependence
on the properties customization point. Practically speaking, it would be
considered a best practice of a high-quality implementation to ensure that a
property’s implementation of <code class="highlight"><span class="n">properties</span><span class="o">::</span><span class="n">element_type_t</span></code> (and other
traits) are invariant with respect to ordering with other known properties
(such as those in the standard library), but with this approach it would be
impossible to make that guarantee formal, particularly with respect to other
vendor-defined and user-defined properties unknown to the property implementer.
This "best practice" enforcement of order invariance is, in some sense, also an
advantage of this specifying the customization point action in this way, since
in the event of an unavoidable ordering dependency the behavior is both
well-defined and easily explained in terms of a relatively simple mechanism.
This also makes sense in terms of defining an order for invocation of hooks
(discussed below), which may be needed to implement some properties.</p>
   <h4 class="heading settled" data-level="3.1.2" id="altconf"><span class="secno">3.1.2. </span><span class="content">Alternative means of resolving conflicts</span><a class="self-link" href="#altconf"></a></h4>
   <p>A second approach to resolving conflicts between two properties
customizing the same member type trait (or most of the other traits) is to
disallow it and to make this the <em>definition</em> of property
incompatibility.  Other than eliminating order dependence, this approach has the
advantage of producing a clean, easy-to-explain definition of property
incompatibility.  However, there are several key disadvantages to this approach.
First, the implementations of many property traits will be
implementation-defined, which implies that one implementation may specialize a
trait for a given property and another may use a different mechanism
(e.g., specialization of a different trait).  This leads to the uncomfortable
scenario where either the mechanism for implementation of any standardized
properties needs to be specified, or (much worse) the compatibility
between properties is implementation-defined.  Beyond this, not all mututally
exclusive modes of a given property may modify the same property traits.
For instance, in the example above with <code class="highlight"><span class="n">read</span></code>/<code class="highlight"><span class="n">write</span></code>/<code class="highlight"><span class="n">read_write</span></code>/<code class="highlight"><span class="n">read_discard</span></code>/etc.
modes of some property (which we called <code class="highlight"><span class="n">access_mode</span></code> for the sake of
discussion), the <code class="highlight"><span class="n">read</span></code> and <code class="highlight"><span class="n">read_discard</span></code> modes would likely specialize <code class="highlight"><span class="n">properties</span><span class="o">::</span><span class="n">reference_t</span></code> to be a <code class="highlight"><span class="k">const</span></code> reference to the <code class="highlight"><span class="n">value_type</span></code> of the <code class="highlight"><span class="n">span</span></code> or <code class="highlight"><span class="n">mdspan</span></code>, but there is no equivalent specialization for the <code class="highlight"><span class="n">write</span></code> mode.  Thus, to enforce the mutual exclusivity that is obvious from the
property’s definition, one would need to define a special case that specifies
incompatibility <em>in spite of</em> trait-wise compatibility.</p>
   <h3 class="heading settled" data-level="3.2" id="data-access-hooks"><span class="secno">3.2. </span><span class="content">Data Access Hooks</span><a class="self-link" href="#data-access-hooks"></a></h3>
   <p>Similar to the property member type traits from above, it is desirable to
define the effects of properties on <code class="highlight"><span class="n">span</span></code> and <code class="highlight"><span class="n">mdspan</span></code> methods in a
manner that is both orthogonal to that of other properties and separate from
the implementation of the property-free implementations for <code class="highlight"><span class="n">span</span></code> and <code class="highlight"><span class="n">mdspan</span></code>. 
Applying the same namespace-scope traits pattern in, e.g., <a data-link-type="biblio" href="#biblio-p0443r3">[P0443R3]</a>, we can
define ADL-accessible hooks that property implementers would customize to
implement the property’s behavior.</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="kr">typename</span> <span class="n">SpanLike</span><span class="o">::</span><span class="n">index_type_t</span>
<span class="n">pre_subscript_operator_hook</span><span class="p">(</span><span class="n">SpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="n">class</span> <span class="n">SpanLike</span><span class="o">::</span><span class="n">index_type_t</span> <span class="n">i</span><span class="p">)</span> <span class="n">noexcept</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="kt">void</span> <span class="n">post_subscript_operator_hook</span><span class="p">(</span><span class="n">SpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="n">class</span> <span class="n">SpanLike</span><span class="o">::</span><span class="n">index_type_t</span> <span class="n">i</span><span class="p">)</span> <span class="n">noexcept</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">IndexType</span><span class="o">></span>
<span class="n">std</span><span class="o">::</span><span class="n">tuple</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="o">&amp;&amp;</span><span class="p">...</span><span class="o">></span>
<span class="n">pre_call_operator_hook</span><span class="p">(</span><span class="n">SpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="n">IndexType</span><span class="o">&amp;&amp;</span><span class="p">...</span> <span class="n">idxs</span><span class="p">)</span> <span class="n">noexcept</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">IndexType</span><span class="o">></span>
<span class="kt">void</span> <span class="n">post_call_operator_hook</span><span class="p">(</span><span class="n">SpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="n">IndexType</span><span class="o">&amp;&amp;</span><span class="p">...</span> <span class="n">idxs</span><span class="p">)</span> <span class="n">noexcept</span><span class="p">;</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="p">,</span> <span class="n">class</span> <span class="n">IndexType</span><span class="p">,</span> <span class="kt">size_t</span> <span class="n">N</span><span class="o">></span>
<span class="n">array</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="p">,</span> <span class="n">N</span><span class="o">></span> <span class="k">const</span><span class="o">&amp;</span>
<span class="n">pre_call_operator_hook</span><span class="p">(</span><span class="n">SpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="n">array</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="p">,</span> <span class="n">N</span><span class="o">></span> <span class="k">const</span><span class="o">&amp;</span> <span class="n">idxs</span><span class="p">)</span> <span class="n">noexcept</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">SpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="p">,</span> <span class="n">class</span> <span class="n">IndexType</span><span class="o">></span>
<span class="kt">void</span> <span class="n">post_call_operator_hook</span><span class="p">(</span><span class="n">SpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="n">array</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="p">,</span> <span class="n">N</span><span class="o">></span> <span class="k">const</span><span class="o">&amp;</span> <span class="n">idxs</span><span class="p">)</span> <span class="n">noexcept</span><span class="p">;</span>

<span class="p">}}}</span>
</pre>
   <p>The intent is that the pre-invocation hooks would take the arguments of the
method invocation and return the (potentially modified) arguments to be used
with the next property hook or the implementation of the method in the
property-free <code class="highlight"><span class="n">span</span></code>/<code class="highlight"><span class="n">mdspan</span></code> implementation of that method.  For instance, a
possible implementation of <code class="highlight"><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">>::</span><span class="k">operator</span><span class="p">()</span></code> would be</p>
<pre class="language-c++ highlight"><span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">DataType</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties</span><span class="o">></span>
<span class="n">class</span> <span class="n">mdspan</span> <span class="p">{</span>
<span class="nl">public</span><span class="p">:</span>
  <span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">IndexType</span><span class="p">,</span> <span class="kt">size_t</span> <span class="n">N</span><span class="o">></span>
  <span class="n">reference</span> <span class="n">operator</span><span class="p">()(</span><span class="n">array</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="p">,</span><span class="n">N</span><span class="o">></span> <span class="k">const</span><span class="o">&amp;</span> <span class="n">indices</span><span class="p">)</span> <span class="k">const</span> <span class="n">noexcept</span> <span class="p">{</span>
    <span class="c1">// remove Property and call the next less-property-qualified implementation</span>
<span class="c1"></span>    <span class="c1">// Optimizer should be able to remove spurious copy here (if not, inheritence</span>
<span class="c1"></span>    <span class="c1">// could be used internally to achieve the same effect)</span>
<span class="c1"></span>    <span class="k">auto</span> <span class="n">rv</span> <span class="o">=</span> <span class="n">mdspan</span><span class="o">&lt;</span><span class="n">DataType</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">></span><span class="p">(</span><span class="o">*</span><span class="n">this</span><span class="p">).</span><span class="n">operator</span><span class="p">()(</span>
      <span class="c1">// intentionally use the unqualified type to trigger ADL</span>
<span class="c1"></span>      <span class="n">pre_call_operator_hook</span><span class="p">(</span><span class="o">*</span><span class="n">this</span><span class="p">,</span> <span class="n">Property</span><span class="p">{},</span> <span class="n">indices</span><span class="p">)</span>
    <span class="p">);</span>
    <span class="n">post_call_operator_hook</span><span class="p">(</span><span class="o">*</span><span class="n">this</span><span class="p">,</span> <span class="n">Property</span><span class="p">{},</span> <span class="n">indices</span><span class="p">);</span>
    <span class="k">return</span> <span class="n">rv</span><span class="p">;</span>
  <span class="p">}</span>
  <span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span><span class="p">...</span> <span class="n">IndexType</span><span class="o">></span>
  <span class="n">reference</span> <span class="n">operator</span><span class="p">()(</span><span class="n">IndexType</span><span class="o">&amp;&amp;</span><span class="p">...</span> <span class="n">indices</span><span class="p">)</span> <span class="k">const</span> <span class="n">noexcept</span> <span class="p">{</span>
    <span class="c1">// similar, but slightly more complicated because of the variadic template</span>
<span class="c1"></span>    <span class="k">auto</span> <span class="n">rv</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">apply</span><span class="p">(</span>
      <span class="p">[</span><span class="n">this</span><span class="p">](</span><span class="n">IndexType</span><span class="o">&amp;&amp;</span><span class="p">...</span> <span class="n">idxs</span><span class="p">){</span> 
          <span class="n">mdspan</span><span class="o">&lt;</span><span class="n">DataType</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">></span><span class="p">(</span><span class="o">*</span><span class="n">this</span><span class="p">).</span><span class="n">operator</span><span class="p">()(</span><span class="n">std</span><span class="o">::</span><span class="n">forward</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="o">></span><span class="p">(</span><span class="n">idxs</span><span class="p">)...);</span>
      <span class="p">},</span>
      <span class="n">pre_call_operator_hook</span><span class="p">(</span><span class="o">*</span><span class="n">this</span><span class="p">,</span> <span class="n">Property</span><span class="p">{},</span> <span class="n">std</span><span class="o">::</span><span class="n">forward</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="o">></span><span class="p">(</span><span class="n">indices</span><span class="p">)...)</span>
    <span class="p">);</span>
    <span class="n">post_call_operator_hook</span><span class="p">(</span><span class="o">*</span><span class="n">this</span><span class="p">,</span> <span class="n">Property</span><span class="p">{},</span> <span class="n">std</span><span class="o">::</span><span class="n">forward</span><span class="o">&lt;</span><span class="n">IndexType</span><span class="o">></span><span class="p">(</span><span class="n">indices</span><span class="p">)...);</span>
    <span class="k">return</span> <span class="n">rv</span><span class="p">;</span>
  <span class="p">}</span>
<span class="p">};</span>
</pre>
   <p>Again, the question of order-invariance arises, though in this case it is much
harder to detect the presence or absense of a customization for a given
property (if an order-independent approach is favored in spite of the issues
raised in <a href="#altconf">§3.1.2 Alternative means of resolving conflicts</a>, it may be desirable to use the "monolithic traits class"
approach instead, similar to the approach of <code class="highlight"><span class="n">allocator_traits</span></code>).  Though best
practice should be that the actions taken by these hooks are order independent,
guaranteeing this for any one property may not be reasonable.  Additionally,
even if the actions of two hooks are entirely independent and could be reordered
by the compiler, it may be useful to understand the hook application order for
performance purposes.</p>
   <h3 class="heading settled" data-level="3.3" id="layout-related-traits-and-hooks-for-mdspan-only"><span class="secno">3.3. </span><span class="content">Layout-Related Traits and Hooks for <code class="highlight"><span class="n">mdspan</span></code> Only</span><a class="self-link" href="#layout-related-traits-and-hooks-for-mdspan-only"></a></h3>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">is_always_unique</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="kr">inline</span> <span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">is_always_unique_v</span> <span class="o">=</span> <span class="n">is_always_unique</span><span class="o">&lt;</span><span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">value</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">is_unique</span><span class="p">(</span><span class="n">MDSpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">);</span>


<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">is_always_contiguous</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="kr">inline</span> <span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">is_always_contiguous_v</span> <span class="o">=</span> <span class="n">is_always_contiguous</span><span class="o">&lt;</span><span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">value</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">is_contiguous</span><span class="p">(</span><span class="n">MDSpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">);</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="k">struct</span> <span class="n">is_always_strided</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="kr">inline</span> <span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">is_always_strided_v</span> <span class="o">=</span> <span class="n">is_always_strided</span><span class="o">&lt;</span><span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">Property</span><span class="o">>::</span><span class="n">value</span><span class="p">;</span>
<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">is_strided</span><span class="p">(</span><span class="n">MDSpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">);</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="kr">typename</span> <span class="n">MDSpanLike</span><span class="p">,</span> <span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">constexpr</span> <span class="n">index_type_t</span><span class="o">&lt;</span><span class="n">MDSpanLike</span><span class="o">></span> <span class="n">stride</span><span class="p">(</span><span class="n">MDSpanLike</span> <span class="n">s</span><span class="p">,</span> <span class="n">Property</span> <span class="n">p</span><span class="p">,</span> <span class="kt">int</span> <span class="n">i</span><span class="p">);</span>

<span class="p">}}}</span>
</pre>
   <p>The layout-related property traits needed to implement <code class="highlight"><span class="n">mdspan</span></code> are a bit of a
special case.  It doesn’t really make sense to talk about what happens when
multiple properties specialize these traits, and trying to formulate these
traits in a form that can be applied multiple times leads to more confusing and
less intuitive definitions of the traits (e.g., one could imagine that <code class="highlight"><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span> <span class="n">Properties</span><span class="p">...</span><span class="o">>::</span><span class="n">stride</span><span class="p">()</span></code> is implemented in terms of the sum of the
return values from the invocations of the customization points with each of the
properties separately, and the default implementation of the customization point
for properties that don’t care about stride could return 0).</p>
   <p>There are a few approaches to explore for addressing this
inconsistency.  Taking the approach that no two properties given for the same <code class="highlight"><span class="n">span</span></code>/<code class="highlight"><span class="n">mdspan</span></code> are allowed to specialize the same customization point makes
layout-like properties more regular, and perhaps this increase in simplicity is
enough to outweigh the disadvantages discussed in <a href="#altconf">§3.1.2 Alternative means of resolving conflicts</a>.  Another option
is to provide some sort of trait that says whether or not a property expects to
be the only one specializing its customization points; something like <code class="highlight"><span class="n">is_unique_customization_v</span></code>.  This is the most complex solution, but provides
the most flexibility for future property extensions.  It also lends itself to an
progressive specification strategy by which new properties "lock down" there
customization point specializations until a compelling use case is presented
requiring interoperability.  (A more aggressive version of this approach may
even specify the expected uniqueness of the customization on a per-trait basis.)
A third option is to just exclude layout-like properties from the ontology
entirely and instead treat it as part of the base <code class="highlight"><span class="n">mdspan</span></code> class template.  This
third approach seems sensible in light of the fact that layout properties don’t
really apply to <code class="highlight"><span class="n">span</span></code>, so its inclusion in the wider ontology may be
unnecessary.  This third strategy almost certainly makes the most sense for the <code class="highlight"><span class="n">extents</span></code> property proposed in <a data-link-type="biblio" href="#biblio-p0009r4">[P0009r4]</a>, since it is mandatory for <code class="highlight"><span class="n">mdspan</span></code>,
affects most of the <code class="highlight"><span class="n">mdspan</span></code> implementation, and does not apply to <code class="highlight"><span class="n">span</span></code>.</p>
   <h3 class="heading settled" data-level="3.4" id="traits-for-propagation-into-or-through-generic-contexts"><span class="secno">3.4. </span><span class="content">Traits for Propagation into or through Generic Contexts</span><a class="self-link" href="#traits-for-propagation-into-or-through-generic-contexts"></a></h3>
   <p>As discussed above in <a href="#gencon">§2.5 On Transmission into Generic Contexts</a>, it is desirable for generic function
templates to deduce and propagate some properties, while for others it is
dangerous to do so.  One potential solution to this problem that doesn’t require
an "all-or-nothing" approach is to have individual properties specify whether or
not they should be propagated through a generic context that otherwise makes no
mention of the property.  For instance, a generic function template that takes
two <code class="highlight"><span class="n">mdspan</span></code> arguments should never deduce <code class="highlight"><span class="n">restrict_access</span></code> as a property of
its arguments unless that function is explicitly implemented to obey the <code class="highlight"><span class="n">restrict_access</span></code> contract.  For instance, consider a generic,
non-<code class="highlight"><span class="n">restrict_access</span></code>-aware function template that calls a generic, <code class="highlight"><span class="n">restrict_access</span></code>-aware dot product function (implemented with separate
overloads for <code class="highlight"><span class="n">restrict_access</span></code> arguments and non-<code class="highlight"><span class="n">restrict_access</span></code> arguments):</p>
<pre class="language-c++ highlight"><span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">T1</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties1</span><span class="p">,</span> <span class="n">class</span> <span class="n">T2</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties2</span><span class="o">></span>
<span class="k">auto</span> <span class="n">my_generic_function</span><span class="p">(</span><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T1</span><span class="p">,</span> <span class="n">Properties1</span><span class="p">...</span><span class="o">></span> <span class="n">s1</span><span class="p">,</span> <span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T2</span><span class="p">,</span> <span class="n">Properties2</span><span class="p">...</span><span class="o">></span> <span class="n">s2</span><span class="p">)</span> <span class="p">{</span>
    <span class="k">return</span> <span class="n">generic_dot</span><span class="p">(</span><span class="n">s1</span><span class="p">,</span> <span class="n">s1</span><span class="p">)</span> <span class="o">+</span> <span class="n">generic_dot</span><span class="p">(</span><span class="n">s2</span><span class="p">,</span> <span class="n">s2</span><span class="p">);</span>
<span class="p">}</span>
</pre>
   <p>If <code class="highlight"><span class="n">restrict_access</span></code> is deduced to be one of the properties of <code class="highlight"><span class="n">s1</span></code> or <code class="highlight"><span class="n">s2</span></code>,
then <code class="highlight"><span class="n">my_generic_function</span></code> has unknowingly called the incorrect overload of <code class="highlight"><span class="n">generic_dot</span></code>, causing it to potentially violate the contract implied by the <code class="highlight"><span class="n">restrict_access</span></code> property.  If, on the other hand, the arguments <code class="highlight"><span class="n">s1</span></code> and <code class="highlight"><span class="n">s2</span></code> have the <code class="highlight"><span class="n">atomic_access</span></code> property enabled (see P0860), it is clearly the intent
of the caller that <code class="highlight"><span class="n">my_generic_function</span></code> and all of its callees make use of the
underlying data via atomic loads, stores, etc. (likely implemented via a wrapper
to the <code class="highlight"><span class="n">reference_t</span></code>; see details in P0860).  The generic context should thus
preserve the <code class="highlight"><span class="n">atomic_access</span></code> property but discard the <code class="highlight"><span class="n">restrict_access</span></code> property.</p>
   <p>One potential solution to this problem is to introduce a trait that returns the
mode of the property intended for propagation through a generic interface.  The
trait would look something like:</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">Property</span><span class="o">></span>
<span class="n">using</span> <span class="n">generic_context_propagation_mode_t</span> <span class="o">=</span> <span class="cm">/* implementation defined */</span><span class="p">;</span>

<span class="p">}}}</span>
</pre>
   <p>Implementers could then rewrite <code class="highlight"><span class="n">my_generic_function</span></code> as:</p>
<pre class="language-c++ highlight"><span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">T1</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties1</span><span class="p">,</span> <span class="n">class</span> <span class="n">T2</span><span class="p">,</span> <span class="n">class</span><span class="p">...</span> <span class="n">Properties2</span><span class="o">></span>
<span class="k">auto</span> <span class="n">my_generic_function</span><span class="p">(</span><span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T1</span><span class="p">,</span> <span class="n">Properties1</span><span class="p">...</span><span class="o">></span> <span class="n">s1</span><span class="p">,</span> <span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T2</span><span class="p">,</span> <span class="n">Properties2</span><span class="p">...</span><span class="o">></span> <span class="n">s2</span><span class="p">)</span> <span class="p">{</span>
    <span class="k">auto</span> <span class="n">s1g</span> <span class="o">=</span> <span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T1</span><span class="p">,</span> <span class="n">properties</span><span class="o">::</span><span class="n">generic_context_propagation_mode_t</span><span class="o">&lt;</span><span class="n">Properties1</span><span class="o">></span><span class="p">...</span><span class="o">></span><span class="p">(</span><span class="n">s1</span><span class="p">);</span>
    <span class="k">auto</span> <span class="n">s2g</span> <span class="o">=</span> <span class="n">mdspan</span><span class="o">&lt;</span><span class="n">T2</span><span class="p">,</span> <span class="n">properties</span><span class="o">::</span><span class="n">generic_context_propagation_mode_t</span><span class="o">&lt;</span><span class="n">Properties2</span><span class="o">></span><span class="p">...</span><span class="o">></span><span class="p">(</span><span class="n">s2</span><span class="p">);</span>
    <span class="k">return</span> <span class="nf">generic_dot</span><span class="p">(</span><span class="n">s1g</span><span class="p">,</span> <span class="n">s1g</span><span class="p">)</span> <span class="o">+</span> <span class="n">generic_dot</span><span class="p">(</span><span class="n">s2g</span><span class="p">,</span> <span class="n">s2g</span><span class="p">);</span>
<span class="p">}</span>
</pre>
   <p>Supposing that <code class="highlight"><span class="n">restrict_access</span></code> is short for something like <code class="highlight"><span class="n">restrict_access_enabled</span><span class="o">&lt;</span>true<span class="o">></span></code>, the trait <code class="highlight"><span class="n">generic_context_propagation_mode_t</span></code> could be specialized for <code class="highlight"><span class="n">restrict_access</span></code> to return <code class="highlight"><span class="n">restrict_access_enabled</span><span class="o">&lt;</span>false<span class="o">></span></code>.</p>
   <p>Another option is to discourage deduction of property template parameters and
rely on conversion and compatibility to prevent accidental failure to propagate
a property.  For instance, the <code class="highlight"><span class="n">atomic_access</span></code> property could prohibit casting
away <code class="highlight"><span class="n">atomic_access</span></code> to avoid accidental usage via non-atomic operations.  This
means that library implementers would have to implement more overloads that they
otherwise would, but the simplification may be worth it.  The need for
implementation of multiple overloads when different properties are present may
exist anyway, since <code class="highlight"><span class="n">atomic_access</span></code> changes the type (and thus the API) of the
reference returned by the subscript and call operators.  Though this option
somewhat limits vendor-specific extensibility (and particularly limits
user-specific extensibility), it appears to be reasonable in the contexts of the
properties proposed thus far.</p>
   <h3 class="heading settled" data-level="3.5" id="traits-for-expression-of-convertibility"><span class="secno">3.5. </span><span class="content">Traits for Expression of Convertibility</span><a class="self-link" href="#traits-for-expression-of-convertibility"></a></h3>
   <p>While it seems wise to require all <code class="highlight"><span class="n">mdspan</span></code> instantiations be convertible to and
from all <code class="highlight"><span class="n">mdspan</span></code> instantiations with different properties, it is reasonable for
properties to restrict which of their modes are interconvertible.  This, then,
requires trait customization points for expressing whether two property modes
belong to the same property as well as whether copy operations are allowed
between any pair of modes of the same property.</p>
<pre class="language-c++ highlight"><span class="n">namespace</span> <span class="n">std</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">experimental</span> <span class="p">{</span>
<span class="n">namespace</span> <span class="n">properties</span> <span class="p">{</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">PropertyInMode1</span><span class="p">,</span> <span class="n">class</span> <span class="n">PropertyInMode2</span><span class="o">></span>
<span class="kr">inline</span> <span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">modes_of_same_property_v</span> <span class="o">=</span> <span class="cm">/* implementation defined */</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">PropertyInMode1</span><span class="o">></span>
<span class="n">using</span> <span class="n">default_mode_for_property_t</span> <span class="o">=</span> <span class="cm">/* implementation defined */</span>

<span class="n">template</span> <span class="o">&lt;</span><span class="n">class</span> <span class="n">PropertyInMode1</span><span class="p">,</span> <span class="n">class</span> <span class="n">PropertyInMode2</span><span class="o">></span>
<span class="kr">inline</span> <span class="n">constexpr</span> <span class="kt">bool</span> <span class="n">are_convertible_property_modes_v</span> <span class="o">=</span> <span class="cm">/* implementation defined */</span>

<span class="p">}}}</span>
</pre>
   <p>With this definition, there is some question as to whether the property itself
should be required to have some sort of identifying tag that, for instance, can
be used with <code class="highlight"><span class="n">is_same</span></code> to determine if two property modes are of the same
property.  This topic can be discussed further as the abstractions proposed
herein are hardened.</p>
   <h3 class="heading settled" data-level="3.6" id="other-potential-traits-and-hooks"><span class="secno">3.6. </span><span class="content">Other Potential Traits and Hooks</span><a class="self-link" href="#other-potential-traits-and-hooks"></a></h3>
   <p>Other places where traits or hooks may need to be placed in the future include
post-construction, pre- and post-assignment, pre- and post-iterator creation
(<code class="highlight"><span class="n">span</span></code> only), iterator member type (<code class="highlight"><span class="n">span</span></code> only), comparison (<code class="highlight"><span class="n">span</span></code> only),
subspan creation, and <code class="highlight"><span class="n">span</span></code> conversion (<code class="highlight"><span class="n">mdspan</span></code> only).  Traits and hooks for
these customization points have not been included here because there has not yet
been a property proposed that would make use of these.  The patterns established
herein for the other traits and hooks should be reasonably applicable to these
cases, however.</p>
   <h2 class="heading settled" data-level="4" id="open-questions-and-straw-polls"><span class="secno">4. </span><span class="content">Open Questions and Straw Polls</span><a class="self-link" href="#open-questions-and-straw-polls"></a></h2>
   <ul>
    <li data-md="">
     <p>Should <code class="highlight"><span class="n">extents</span></code> (and to a lesser extent, <code class="highlight"><span class="n">layout</span></code>) from <a data-link-type="biblio" href="#biblio-p0009r4">[P0009r4]</a> be made
to fit in this property ontology, or should these be part of the <code class="highlight"><span class="n">mdspan</span></code> class template itself (and thus subject to different rules).  (Stated
differently, should the property ontology and traits proposed herein be
adapted to accomodate <code class="highlight"><span class="n">extents</span></code> and <code class="highlight"><span class="n">layout</span></code>?)</p>
    <li data-md="">
     <p>Straw poll: Should the customization of the same trait/hook by multiple
properties be allowed (with conflicts resolved via order dependence), or
should customization point conflicts be used as an indicator of
incompatibility?</p>
    <li data-md="">
     <p>Straw poll: If customization of the same trait/hook by multiple properties is
allowed, should a trait like <code class="highlight"><span class="n">is_unique_customization_v</span></code> be provided that 
prohibits multiple customization on a case-by-case basis?</p>
    <li data-md="">
     <p>Straw poll: Should the traits customization points proposed here be
implemented at namespace scope or as part of a monolithic traits class?</p>
    <li data-md="">
     <p>Straw poll: Should the guidance be to propagate properties via the
instructions of a trait like <code class="highlight"><span class="n">generic_context_propagation_mode_t</span></code>, or should
the guidance be to not propagate properties via template argument
deduction?</p>
   </ul>
  </main>

		Active content removed
	
  <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-p0009r4">[P0009r4]
   <dd>H. Carter Edwards, Bryce Lelbach, Christian Trott, Mauro Bianco, Robin Maffeo, Ben Sander, Athanasios Iliopoulos, John Michopoulos. <a href="https://wg21.link/p0009r4">Polymorphic Multidimensional Array Reference</a>. URL: <a href="https://wg21.link/p0009r4">https://wg21.link/p0009r4</a>
   <dt id="biblio-p0019r5">[P0019r5]
   <dd>H. Carter Edwards, Hans Boehm, Olivier Giroux, James Reus. <a href="https://wg21.link/p0019r5">Atomic View</a>. URL: <a href="https://wg21.link/p0019r5">https://wg21.link/p0019r5</a>
   <dt id="biblio-p0367r0">[P0367r0]
   <dd>Ronan Keryell, Joël Falcou. <a href="https://wg21.link/p0367r0">a C++ standard library class to qualify data accesses</a>. 29 May 2016. URL: <a href="https://wg21.link/p0367r0">https://wg21.link/p0367r0</a>
   <dt id="biblio-p0443r3">[P0443R3]
   <dd>Jared Hoberock, Michael Garland, Chris Kohlhoff, Chris Mysen, Carter Edwards, Gordon Brown. <a href="https://wg21.link/p0443r3">A Unified Executors Proposal for C++</a>. URL: <a href="https://wg21.link/p0443r3">https://wg21.link/p0443r3</a>
   <dt id="biblio-p0546r1">[P0546r1]
   <dd>Carter Edwards, Bryce Lelbach. <a href="https://wg21.link/p0546r1">Span - foundation for the future</a>. URL: <a href="https://wg21.link/p0546r1">https://wg21.link/p0546r1</a>
  </dl>