<!DOCTYPE html>
<html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
  <title>P0340R0</title>
  <style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
</style>
</head>
<body>
<h1 id="making-std-underlying_type-sfinae-friendly">Making <code>std::underlying_type</code> SFINAE-friendly</h1>
<table>
<tbody>
<tr>
<td>Document number:</td>
<td>P0340R0</td>
</tr>
<tr>
<td>Date:</td>
<td>2016-05-30</td>
</tr>
<tr>
<td>Audience:</td>
<td>Library Evolution Working Group</td>
</tr>
<tr>
<td>Reply to:</td>
<td>R. "Tim" Song &lt;rs2740@gmail.com&gt;</td>
</tr>
</tbody>
</table>
<h2 id="abstract">Abstract</h2>
<p>This paper proposes making <code>std::underlying_type</code> SFINAE-friendly. In particular, it would make instantiating <code>std::underlying_type&lt;T&gt;</code> for a non-enumeration type <code>T</code> well-defined and result in an empty struct.</p>
<h2 id="motivation">Motivation</h2>
<p>Currently, <code>std::underlying_type&lt;T&gt;</code> requires <code>T</code> to be a complete enumeration type. instantiating it with any other type results in undefined behavior, typically a hard error. This makes it tricky to use in SFINAE contexts. For example, if one wants to write a function template that want to constrain a template argument to "enumeration type whose underlying type is <code>int</code>", the "obvious" approach would be something along the lines of</p>
<pre><code>template&lt;class T&gt;
std::enable_if_t&lt;std::is_enum_v&lt;T&gt; &amp;&amp;
                 std::is_same_v&lt;std::underlying_type_t&lt;T&gt;, int&gt;&gt; foo(T t);
</code></pre><p>Unfortunately, this won't work; writing <code>foo(0)</code> will almost certainly result in a hard error, even if there is a <code>void foo(int);</code> overload available. Instead, actual evaluation of <code>std::underlying_type&lt;T&gt;</code> must be deferred until <code>T</code> is known to be an enum, with something like</p>
<pre><code>template&lt;class T&gt;
std::enable_if_t&lt;std::is_same_v&lt;typename std::enable_if_t&lt;std::is_enum_v&lt;T&gt;, std::underlying_type&lt;T&gt;&gt;::type, int&gt;&gt; foo(T t);
</code></pre><p>Not only is this harder to write (<code>typename ...::type</code>), it is also harder to understand (nested <code>enable_if</code>s).</p>
<p>This is a recurring problem on StackOverflow; see for example <a href="http://stackoverflow.com/q/36568050/2756719">1</a>, <a href="http://stackoverflow.com/q/35746062/2756719">2</a>, <a href="http://stackoverflow.com/q/35152818/2756719">3</a>, all from 2016.</p>
<p>If <code>std::underlying_type&lt;T&gt;</code> is well-defined but has no member <code>type</code> when <code>T</code> is not an enumeration type, then the above function template can be simplified to</p>
<pre><code>template&lt;class T&gt;
std::enable_if_t&lt;std::is_same_v&lt;std::underlying_type_t&lt;T&gt;, int&gt;&gt; foo(T t);
</code></pre><p>which is shorter, more intuitive, and easier to understand.</p>
<p>It's worth noting that libc++ has a <code>__sfinae_underlying_type</code> for internal use with an implementation very similar to that described below (but with an additional helper member typedef).</p>
<h2 id="impact-on-the-standard">Impact on the standard</h2>
<p>This is a pure extension, as currently instantiating <code>std::underlying_type</code> over a non-enumeration type results in undefined behavior, typically a compile-time error.</p>
<h2 id="design-alternatives">Design alternatives</h2>
<p>A possible alternative would be to make the nested typedef <code>type</code> return the type unchanged if <code>T</code> is not an enumeration type, matching the behavior of some other TransformationTraits such as <code>add_lvalue_reference</code> and <code>remove_extent</code>. This approach also avoids hard errors. This author, however, does not see reasons to make <code>underlying_type_t&lt;int&gt;</code> well-formed.</p>
<p>Another design alternative would be to support <code>char16_t</code>, <code>char32_t</code>, and <code>wchar_t</code>, each of which also has a "underlying type" (see [basic.fundamental]/5). And though the standard doesn't use the term, one might say that plain <code>char</code> similarly has an "underlying type" of either <code>signed char</code> or <code>unsigned char</code> depending on the implementation. The current specification in the standard permits implementations to support those types as an extension, though the author is not aware of any implementation that does so. In the author's opinion, the two categories are sufficiently distinct that lumping them into the same type trait would not be advisable.</p>
<p>The prohibition against incomplete enumeration types is left undisturbed, given the potential for ODR violations, and since the benefit from supporting such types is minimal at best.</p>
<h2 id="proposed-wording">Proposed wording</h2>
<p> Edit the table in  [meta.trans.other] as indicated:</p>
<table border="1">
<thead>
<tr>
<th>Template</th>
<th>Condition</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td><code>template &lt;class T&gt;</code><br/><code>struct underlying_type;</code></td>
<td><del><code>T</code> shall be a complete enumeration type (7.2)</del> <ins>If <code>T</code> is an enumeration type, <code>T</code> shall be a complete type.</td>
<td><ins> If <code>T</code> is an enumeration type, the </ins><del>The</del> member typedef <code>type</code> shall name the underlying type of <code>T</code><ins>; otherwise, there shall be no member <code>type</code></ins>.</td>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
</tbody>
</table>
<h2 id="possible-implementation">Possible implementation</h2>
<p> Given an intrinsic <code>__underlying_type(T)</code> (which is already needed to implement the current version of <code>underlying_type</code>), the implementation is trivial:</p>
<pre><code> template&lt;class T, bool = std::is_enum_v&lt;T&gt;&gt; struct _Underlying_type {};
 template&lt;class T&gt; struct _Underlying_type&lt;T, true&gt; { using type = __underlying_type(T); };

 template&lt;class T&gt; struct underlying_type : _Underlying_type&lt;T&gt; { };
</code></pre>

</body></html>