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.
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.
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.
1. In "3.2.2 Class
decimal32" synopsis, remove the
explicit specifier from the narrowing conversions:
// 184.108.40.206 conversion from floating-point type:
explicitdecimal32(decimal64 d64); explicitdecimal32(decimal128 d128);
2. Do the same thing in "220.127.116.11. Conversion from floating-point type."
3. In "3.2.3 Class
decimal64" synopsis, remove the
explicit specifier from the narrowing conversion:
// 18.104.22.168 conversion from floating-point type:
4. Do the same thing in "22.214.171.124. Conversion from floating-point type."
[ Redmond: We prefer explicit conversions for narrowing and implicit for widening. ]