<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 597: [dec.tr] The notion of 'promotion' cannot be emulated by user-defined types.</title>
<meta property="og:title" content="Issue 597: [dec.tr] The notion of 'promotion' cannot be emulated by user-defined types.">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue597.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  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}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD">NAD</a> status.</em></p>
<h3 id="597"><a href="lwg-closed.html#597">597</a>. [dec.tr] The notion of 'promotion' cannot be emulated by user-defined types.</h3>
<p><b>Section:</b> 3.2 [dec.tr::trdec.types.types] <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Daveed Vandevoorde <b>Opened:</b> 2006-04-05 <b>Last modified:</b> 2016-01-31</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#dec.tr::trdec.types.types">issues</a> in [dec.tr::trdec.types.types].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In a private email, Daveed writes:
</p>
<blockquote>
<p>
I am not familiar with the C TR, but my guess is that the
class type approach still won't match a built-in type
approach because the notion of "promotion" cannot be
emulated by user-defined types.
</p>
<p>
Here is an example:
</p>
</blockquote>
<pre>

         struct S {
           S(_Decimal32 const&amp;);  // Converting constructor
         };
         void f(S);

         void f(_Decimal64);

         void g(_Decimal32 d) {
           f(d);
         }
</pre>

<blockquote>
<p>
If _Decimal32 is a built-in type, the call f(d) will likely
resolve to f(_Decimal64) because that requires only a
promotion, whereas f(S) requires a user-defined conversion.
</p>
<p>
If _Decimal32 is a class type, I think the call f(d) will be
ambiguous because both the conversion to _Decimal64 and the
conversion to S will be user-defined conversions with neither
better than the other.
</p>
</blockquote>
<p>
Robert comments:
</p>
<p>
In general, a library of arithmetic types cannot exactly emulate the behavior of the intrinsic numeric types.  There are several ways to tell whether an implementation of the decimal types uses compiler intrinisics or a library.  For example:
</p>
<pre>
                 _Decimal32 d1;
                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.
</pre>
<p>
In preparing the decimal TR, we have three options:
</p>
<ol>
<li>require that the decimal types be class types</li>
<li>require that the decimal types be builtin types, like float and double</li>
<li>specify a library of class types, but allow enough implementor latitude that a conforming implementation could instead provide builtin types</li>
</ol>
<p>
We decided as a group to pursue option #3, but that approach implies that implementations may not agree on the semantics of certain use cases (first example, above), or on whether certain other cases are well-formed (second example).  Another potentially important problem is that, under the present definition of POD, the decimal classes are not POD types, but builtins will be.
</p>
<p>
Note that neither example above implies any problems with respect to C-to-C++ compatibility, since neither example can be expressed in C.
</p>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Decimal numeric types may either be builtin types or library types. We
only intend to specify the common subset of behaviors of the two
implementation approaches. The front matter of the Decimal TR says this
explicitly.
</p>
<p>
Move to NAD.
</p>
</blockquote>



<p id="res-597"><b>Proposed resolution:</b></p>





</body>
</html>
