Comparison to zero

[m5k8]

That's a little bit of bikeshedding, but nevertheless:

    using distance = si::length<si::metre>;
    distance x = ...;
    if (x == 0)

That doesn't work. So:

    if (x == x.zero())
    if (x == distance::zero())
    if (x == (decltype(x)::zero())
    if (x.number() == 0)

How would you prefer to compare? All variants look somehow not too elegant... Any other way?

[JohelEGP]

x == distance{0}

[mpusz]

There is no way to ensure you are comparing to value 0 and not, for example 42, and we probably agree that if (x == 42) is a really bad idea.

Additionally, with the changes suggested by @burnpanck in #413 (comment), the following will also be correct:

if (x == 0 * m)

[m5k8]

There is no way to ensure you are comparing to value 0 and not, for example 42, and we probably agree that if (x == 42) is a really bad idea.

Obviously, no discussion here. But 0 is a special magic value, hence the presence of ::zero().
I have a code with a LOT of comparisons to 0, and these are of course terse and correct:

    x == distance{0}
    if (x == 0 * m)

But every time, I'm forced to look up the specific correct quantity type of current variable to write it on the right side, and for example using decltype(x)::zero() frees me from this jump somewhere else and back in the code.

Nevermind, minor issue. I was just interested what's your practice. Thanks!

[mpusz]

@m5k8, please note that in the V2, we now have a dedicated interface to check against zero: https://mpusz.github.io/mp-units/2.0/users_guide/framework_basics/quantity_arithmetics/#comparison-against-zero.

[m5k8]

Great! Now I need to find some free time to migrate my code to mpunits 2.0...

[burnpanck]

I actually keep two small utilities in my headers, qZero and qNaN. The former one implicitly converts to any quantity of zero magnitude. The latter one also implicitly converts to quantity_points - in contrast to zero, which only converts to quantities but not quantity_points.
I mainly use those for initialising/setting values to zero or NaN, but it may also work for comparisons (though I'm not 100 % sure it doesn't cause ambiguous calls with mixed unit comparison operators).

Here is the code (still v1):

namespace detail {
template <bool enable_point, typename CB>
struct SpecialValue {
 public:
  template <typename CB_>
  explicit constexpr SpecialValue(std::integral_constant<bool, enable_point>, CB_ &&cb)
      : callback(std::forward<CB_>(cb)) {}

  template <std::floating_point F>
  explicit(false) constexpr operator F() const {
    return F{callback(F{})};
  }

  // avoid implicitly convertible quantities, as those will cause ambiguous conversions using the float variant above
  template <::units::Quantity Q> requires (!std::is_convertible_v<Q,typename Q::rep>)
  explicit(false) constexpr operator Q() const {
    return Q{callback(typename Q::rep{})};
  }

  template <::units::QuantityPoint QP>
    requires enable_point
  explicit(false) constexpr operator QP() const {
    return QP{callback(typename QP::rep{})};
  }

 private:
  CB callback;
};
template <bool en, typename CB>
SpecialValue(std::integral_constant<bool, en>, CB &&) -> SpecialValue<en, std::remove_cvref_t<CB>>;

}  // namespace detail

static constexpr auto qNaN = detail::SpecialValue{
    std::true_type{}, [](auto F) { return std::numeric_limits<decltype(F)>::quiet_NaN(); }};

static constexpr auto qZero =
    detail::SpecialValue{std::false_type{}, [](auto F) { return decltype(F){0}; }};

[chiphogg]

By the way, I'll leave this conceptual discussion of zero here as part of this answer for posterity.

[mpusz]

I Ctrl-F'ed #488 for implicit, and the only justification I could find was that supporting implicit conversions in operator+(quantity, quantity) led to ODR violations and lack of commutativity.

The biggest issue I probably had with implicit conversions was that it does not satisfy the Quantity concept, which means it will not work with generic code or the code that was refactored to be generic from previously working fine strongly typed version of it.

[chiphogg]

That's helpful --- thanks. That makes more sense than the ODR/lack of commutativity explanation.

It makes me wonder: if a type T satisfies a concept C, then does every type R from which T can be implicitly constructed also need to satisfy C? Like, as a general principle? I'd be interested to see if anyone's discussed this before, but I have no idea how to form a search query to find out.

One thing seems clear enough: if this property doesn't hold, then this problem will occur: refactoring the interface from T to C will cause callsites that had passed R to break. I agree that's a problem, but I don't know how big of a problem. 🙂

But in any case, at least for mp-units, it's a moot point since we went with the other local optimum.

[JohelEGP]

It makes me wonder: if a type T satisfies a concept C, then does every type R from which T can be implicitly constructed also need to satisfy C?

No.
That's not part of https://eel.is/c++draft/concepts.equality.

[burnpanck]

We'll see if my qZero survives that refactor :-)

I think it will.

Half a year later and finally on to that refactor: The qZero and qNaN did in fact survive :-D.