<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta http-equiv="Content-Style-Type" content="text/css" />
  <meta name="generator" content="pandoc" />
  <title></title>
  <style type="text/css">code{white-space: pre;}</style>
  <style type="text/css">
div.sourceCode { overflow-x: auto; }
table.sourceCode, tr.sourceCode, td.lineNumbers, td.sourceCode {
  margin: 0; padding: 0; vertical-align: baseline; border: none; }
table.sourceCode { width: 100%; line-height: 100%; }
td.lineNumbers { text-align: right; padding-right: 4px; padding-left: 4px; color: #aaaaaa; border-right: 1px solid #aaaaaa; }
td.sourceCode { padding-left: 5px; }
code > span.kw { color: #007020; font-weight: bold; } /* Keyword */
code > span.dt { color: #902000; } /* DataType */
code > span.dv { color: #40a070; } /* DecVal */
code > span.bn { color: #40a070; } /* BaseN */
code > span.fl { color: #40a070; } /* Float */
code > span.ch { color: #4070a0; } /* Char */
code > span.st { color: #4070a0; } /* String */
code > span.co { color: #60a0b0; font-style: italic; } /* Comment */
code > span.ot { color: #007020; } /* Other */
code > span.al { color: #ff0000; font-weight: bold; } /* Alert */
code > span.fu { color: #06287e; } /* Function */
code > span.er { color: #ff0000; font-weight: bold; } /* Error */
code > span.wa { color: #60a0b0; font-weight: bold; font-style: italic; } /* Warning */
code > span.cn { color: #880000; } /* Constant */
code > span.sc { color: #4070a0; } /* SpecialChar */
code > span.vs { color: #4070a0; } /* VerbatimString */
code > span.ss { color: #bb6688; } /* SpecialString */
code > span.im { } /* Import */
code > span.va { color: #19177c; } /* Variable */
code > span.cf { color: #007020; font-weight: bold; } /* ControlFlow */
code > span.op { color: #666666; } /* Operator */
code > span.bu { } /* BuiltIn */
code > span.ex { } /* Extension */
code > span.pp { color: #bc7a00; } /* Preprocessor */
code > span.at { color: #7d9029; } /* Attribute */
code > span.do { color: #ba2121; font-style: italic; } /* Documentation */
code > span.an { color: #60a0b0; font-weight: bold; font-style: italic; } /* Annotation */
code > span.cv { color: #60a0b0; font-weight: bold; font-style: italic; } /* CommentVar */
code > span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Information */
  </style>
</head>
<body>
<h1 id="put-stdmonostate-in-utility">Put <code>std::monostate</code> in <code>&lt;utility&gt;</code></h1>
<ul>
<li>Document number: P0472R0</li>
<li>Date: 2016-10-14</li>
<li>Reply-to: David Sankel &lt;dsankel@bloomberg.net&gt;</li>
<li>Audience: Library Evolution</li>
</ul>
<h2 id="abstract">Abstract</h2>
<p><code>std::monostate</code> is currently defined and available in the <code>&lt;variant&gt;</code> header, but its utility is not limited to <code>variant</code>s. We propose moving <code>std::monostate</code> to <code>&lt;utility&gt;</code> to reduce artificial coupling of <code>std::monostate</code> clients to variants.</p>
<h2 id="motivation">Motivation</h2>
<p><code>std::monostate</code> is a class that has exactly one value. It is default constructable and supports all the comparison operations. <code>std::monostate</code> is about as simple of a type as one could concoct. These properties turn out to be useful for writing template code.</p>
<p>The first use case is in testing. Does your custom <code>vector</code> or <code>set</code> make any undesirable assumptions about the types they are instantiated with? If they work properly with <code>std::monostate</code>, then probably not. <code>std::monostate</code> can be used in this way as a means to write simple test drivers.</p>
<p>The second use case occurs in more sophisticated template metaprogramming. The well known <code>std::future</code> class makes use of a &quot;special&quot; template parameter <code>void</code> to indicate that it carries no information aside from when the future is fulfilled. Using the <code>void</code> keyword to represent this situation carries a serious implementation burden due to its many strange properties. While this burden may not be a problem for standard library implementers, it would be nice to have a simpler option for the more common developer.</p>
<p><code>std::monostate</code> is a much more natural way to represent &quot;no information&quot; than <code>void</code> is. It has exactly one value and is regular type instead of a keyword. Consider how simple the following code is:</p>
<div class="sourceCode"><pre class="sourceCode cpp"><code class="sourceCode cpp"><span class="kw">template</span>&lt;<span class="kw">typename</span> ExtraInformation = std::monostate&gt;
<span class="kw">class</span> Data
{
  <span class="co">//...</span>
  ExtraInformation m_extraInformation;
}</code></pre></div>
<p>Here we have a <code>Data</code> template which optionally carries extra information. The use of <code>std::monostate</code> in this example makes it simple in both specification and implementation to represent <code>Data</code> objects that carry no additional information.</p>
<h2 id="conclusion">Conclusion</h2>
<p><code>std::monostate</code> is a generally useful type and therefore belongs in a more appropriate header than <code>&lt;variant&gt;</code>. If the committee deems this a worthy course of action, wording will be provided.</p>
</body>
</html>
