<!DOCTYPE html>
<!-- saved from url=(0073)http://wiki.edg.com/pub/Wg21sandiego2018/LibraryWorkingGroup/d0340r2.html -->
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="generator" content="HTML Tidy for HTML5 for Linux version 5.6.0">

<title>D0340R2: Making std::underlying_type SFINAE-friendly</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 { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  del { text-decoration:line-through; 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>P0340R2</td>
</tr>
<tr>
<td>Date:</td>
<td>2018-11-25</td>
</tr>
<tr>
<td>Audience:</td>
<td>LWG</td>
</tr>
<tr>
<td>Reply to:</td>
<td>Tim Song &lt;rs2740@gmail.com&gt;</td>
</tr>
</tbody>
</table>
<h2 id="revision-history">Revision history</h2>
<ul>
<li>R2 (2018-11-25): Updated wording to current WP and removed alternative wording options per LEWG poll. Elaborated on incomplete enumeration types. </li>
<li>R1 (2018-05-07): Updated wording to current WP and added alternative wording options. </li>
</ul>
<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>
<h2 id="wording-notes">Wording notes</h2>
<p>The prohibition against incomplete enumeration types is left
in place, given the potential for ODR violations, and because the
benefit from supporting such types is minimal at best, such types being
so rare in the wild that the author's example has led to him being called
"a twisted, twisted guy". It is promoted to a 
<i>Mandates:</i> element since it is easily diagnosed (and is in fact
diagnosed already in several major implementations).</p>
<p>While an <i>opaque-enum-declaration</i> always declares a complete enumeration type,
incomplete enumeration types can be seen in their own definitions (see [dcl.enum]/6):</p>
<blockquote>
<pre>
enum E {
  a = std::underlying_type_t&lt;E&gt;() // E is incomplete here
} // E becomes complete here
;
</pre>
</blockquote>
<h2 id="proposed-wording">Proposed wording</h2>
<p>This wording is relative to <a href="https://wg21.link/N4778">N4778</a>.
</p><p>Edit the table in [meta.trans.other] as indicated:</p>
<table border="1">
<thead>
<tr>
<th>Template</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<tr>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td><code>template &lt;class T&gt;</code><br>
<code>struct underlying_type;</code></td>
<td>
<p><ins>If <code>T</code> is an enumeration type, the</ins>
<del>The</del> member typedef <code>type</code> names the
underlying type of <code>T</code><ins> (9.6 [dcl.enum]); otherwise, there shall be
no member <code>type</code></ins>.</p>
<p><del><i>Requires:</i><code>T</code> shall be a complete enumeration type
(9.6)</del> <ins><i>Mandates:</i> If <code>T</code> is an enumeration type,
<code>T</code> shall be a complete type.</ins></p>
</td>
</tr>
<tr>
<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>