This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 606. [dec.tr] allow narrowing conversions

Section: 3.2 [dec.tr::trdec.types.types] Status: NAD Submitter: Martin Sebor Opened: 2006-06-15 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 c++std-lib-17205, Martin writes:

> ...was it a deliberate design choice to make narrowing assignments ill-formed while permitting narrowing compound assignments? For instance:

          decimal32 d32;
          decimal64 d64;

          d32 = 64;     // error
          d32 += 64;    // okay

In c++std-lib-17229, Robert responds:

> It is a vestige of an old idea that I forgot to remove from the paper. Narrowing assignments should be permitted. The bug is that the converting constructors that cause narrowing should not be explicit. Thanks for pointing this out.

[ 2009-07 Frankfurt ]

> The current state of the Decimal TR is the result of a deliberate design decision that has been examined many times.

> Move to NAD.

Proposed resolution:

1. In "3.2.2 Class `decimal32`" synopsis, remove the `explicit` specifier from the narrowing conversions:

                    // 3.2.2.2 conversion from floating-point type:
                    explicit decimal32(decimal64 d64);
                    explicit decimal32(decimal128 d128);

2. Do the same thing in "3.2.2.2. Conversion from floating-point type."

3. In "3.2.3 Class `decimal64`" synopsis, remove the `explicit` specifier from the narrowing conversion:

                    // 3.2.3.2 conversion from floating-point type:
                    explicit decimal64(decimal128 d128);

4. Do the same thing in "3.2.3.2. Conversion from floating-point type."

[ Redmond: We prefer explicit conversions for narrowing and implicit for widening. ]