-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: Backlog
-
Component/s: Internal Code
-
None
-
Fully Compatible
-
Dev Tools 2019-06-17, Dev Tools 2019-07-01
Decimal128 are often specified Decimal128("stringliteral").
It seems we could get some clarity and robustness out of a UDL for this type instead.
We might be able to make it constexpr for some extra safety.
Some sample code from a json unit test:
ASSERT(representAs<Decimal128>(Decimal128("5"))->isEqual(Decimal128("5"))); ASSERT(representAs<Decimal128>(Decimal128("5.5"))->isEqual(Decimal128("5.5"))); ASSERT(representAs<Decimal128>(Decimal128("-5"))->isEqual(Decimal128("-5"))); ASSERT(representAs<Decimal128>(Decimal128("-5.5"))->isEqual(Decimal128("-5.5")));
I'd prefer to see this sort of thing as:
using namespace mongo::literals; // or whatever ASSERT(representAs<Decimal128>(5_d128))->isEqual(5_d128))); ASSERT(representAs<Decimal128>(5.5_d128))->isEqual(5.5_d128)); ASSERT(representAs<Decimal128>(-5_d128))->isEqual(-5_d128)); ASSERT(representAs<Decimal128>(-5.5_d128)->isEqual(-5.5_d128));
This is quite squarely what UDLs are all about, really.
- is related to
-
SERVER-24374 Decimal128 constructors taking integers should be constexpr
- Closed