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

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."

[ 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.

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.