597. [dec.tr] The notion of 'promotion' cannot be emulated by user-defined types.

Section: 3.2 [dec.tr::trdec.types.types] Status: NAD Submitter: Daveed Vandevoorde Opened: 2006-04-05 Last modified: 2016-01-31

Priority: Not Prioritized

View all other issues in [dec.tr::trdec.types.types].

View all issues with NAD status.

Discussion:

In a private email, Daveed writes:

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.

Here is an example:

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

         void f(_Decimal64);

         void g(_Decimal32 d) {
           f(d);
         }

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.

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.

Robert comments:

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:

                 _Decimal32 d1;
                 d1.operator+=(5);  // If d1 is a builtin type, this won't compile.

In preparing the decimal TR, we have three options:

1. require that the decimal types be class types
2. require that the decimal types be builtin types, like float and double
3. specify a library of class types, but allow enough implementor latitude that a conforming implementation could instead provide builtin types

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.

Note that neither example above implies any problems with respect to C-to-C++ compatibility, since neither example can be expressed in C.

[ 2009-07 Frankfurt ]

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.

Move to NAD.

Proposed resolution: