Truncation warnings on UDLs

[mpusz]

Problem statement

Typical UDL definition for quantities:

inline namespace literals {

constexpr auto operator"" _q_km(unsigned long long l) { return length<kilometre, std::int64_t>(l); }
constexpr auto operator"" _q_km(long double l) { return length<kilometre, long double>(l); }

}

when compiled with -Wsign-conversion flag results in a compilation warning due to the possibility of losing the sign during conversion from unsigned long long to std::int64_t.

Please vore on the below solutions

[mpusz]

Solution 1 (current state)

Disable the warning for the entire project:

https://github.com/mpusz/units/blob/8193065feb413204c68b0790ab6a5f226e877256/cmake/warnings.cmake#L78-L79

The downside is the fact that if a user has this warning enabled for his/her project the warning will appear and possibly will prevent the successful compilation (if -Werror is used).

[mpusz]

Solution 2

Add explicit static_cast<std::int64_t> for every UDL in the library:

inline namespace literals {

constexpr auto operator"" _q_km(unsigned long long l) { return length<kilometre, std::int64_t>(static_cast<std::int64_t>(l)); }
constexpr auto operator"" _q_km(long double l) { return length<kilometre, long double>(static_cast<std::int64_t>(l)); }

}

The downside is that it hides a possible issue from the user.

[JohelEGP]

Solution 3

Make them consteval, and add a gsl_Expects(std::in_range<std::int64_t>(l)); contract statement.

[JohelEGP]

Ah, yes. There are many such bugs in the GCC Bugzilla about provable non-narrowing conversions and overly enthusiastic warning emissions. Well, since they're warnings, I think you could disable them, or use a pragma around them. Since the compiler is required, anyways, to make this fail when an actual narrowing would occur:

Narrowing conversions
list-initialization limits the allowed implicit conversions by prohibiting the following:

• ...
• conversion from integer or unscoped enumeration type to integer type that cannot represent all values of the original, except where source is a constant expression whose value can be stored exactly in the target type

-- https://en.cppreference.com/w/cpp/language/list_initialization

[mpusz]

I do not want to disable those warnings as in other places they might be useful.

[JohelEGP]

I think this is where pragmas could help by selectively disabling them only around namespace literals.

[mpusz]

It turns out that UDLs cannot be consteval as not every result is assigned to the constexpr object: https://github.com/mpusz/units/runs/1929555500?check_suite_focus=true#step:7:363.

[JohelEGP]

Surely that's a problem with MSVC. Here's an example in the standard of a use of a consteval function to initialize a runtime object: http://eel.is/c++draft/support.srcloc.cons#3.