[SERVER-41425] support for Decimal128 literals Created: 31/May/19  Updated: 29/Oct/23  Resolved: 28/Jun/19

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: Backlog
Fix Version/s: 4.3.1

Type: Improvement Priority: Major - P3
Reporter: Billy Donahue Assignee: Billy Donahue
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-24374 Decimal128 constructors taking intege... Closed
Backwards Compatibility: Fully Compatible
Sprint: Dev Tools 2019-06-17, Dev Tools 2019-07-01
Participants:

 Description   

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.



 Comments   
Comment by Githook User [ 28/Jun/19 ]

Author:

{'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}

Message: SERVER-41425 operator"" _dec128 for Decimal128 literals

Also add unary operator+, operator-.
Branch: master
https://github.com/mongodb/mongo/commit/abe43b7aaddd8254c51eb2c8bfce99b9e11f8fee

Comment by Billy Donahue [ 03/Jun/19 ]

A difficulty here is that we can't make the Decimal128 string parser constexpr (it calls out to the intelfp C library), so we'd have a non-constexpr UDL that can fail at runtime if given a bad literal string, which I think could be unexpected behavior for users.

Generated at Thu Feb 08 04:57:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.