Avoid implicit conversion when converting Quantity to std::complex

[matthew-reynolds]

Avoid implicit conversions when explicitly converting a Quantity to
std::complex<T> (ie with Quantity<T1>::as<std::complex<T2>>()).
This warning was previously suppressed when building with Bazel due
to au headers being included as system headers (See
#440.)

Without this change, this function fails the Quantity test suite
(au/code/au/quantity_test.cc) with -Wfloat-conversion. This is
because we're calling std::complex<int>(const int&, const int&) with a
double. The static_cast<Common>(value_) aka
static_cast<std::complex<int>>(value_) doesn't help us here, we're
still performing an implicit conversion when invoking the constructor.
More generally, when the rep type of the std::complex does not match
the rep type of the Quantity, we're not explicitly casting the
Quantity's rep to the std::complex's, we're just calling the
std::complex<T>(const T&, const T&) constructor.

GCC10:

In file included from au/quantity_test.cc:15:
./au/quantity.hh: In instantiation of 'constexpr auto au::Quantity<UnitT, RepT>::as(NewUnit) const [with NewRep = std::complex<int>; NewUnit = au::QuantityMaker<au::Miles>; <template-parameter-2-3> = void; UnitT = au::Feet; RepT = double]':
au/quantity_test.cc:528:49:   required from here
./au/quantity.hh:184:77: error: conversion from 'au::Quantity<au::Feet, double>::Rep' {aka 'double'} to 'int' may change value [-Werror=float-conversion]
  184 |             static_cast<NewRep>(detail::apply_magnitude(static_cast<Common>(value_), Factor{})));
      |                                                                             ^~~~~~
cc1plus: all warnings being treated as errors

Clang11:

In file included from au/quantity_test.cc:15:
./au/quantity.hh:184:77: error: implicit conversion turns floating-point number into integer: 'const au::Quantity<au::Feet, double>::Rep' (aka 'const double') to 'const std::__1::complex<int>::value_type' (aka 'const int') [-Werror,-Wfloat-conversion]
            static_cast<NewRep>(detail::apply_magnitude(static_cast<Common>(value_), Factor{})));
                                                        ~~~~~~~~~~~         ^~~~~~
au/quantity_test.cc:528:22: note: in instantiation of function template specialization 'au::Quantity<au::Feet, double>::as<std::__1::complex<int>, au::QuantityMaker<au::Miles>, void>' requested here
    const auto b = a.as<std::complex<int>>(miles);
                     ^
1 error generated.

Clang14:

In file included from au/quantity_test.cc:15:
./au/quantity.hh:184:77: error: implicit conversion turns floating-point number into integer: 'const au::Quantity<au::Feet, double>::Rep' (aka 'const double') to 'const std::complex<int>::value_type' (aka 'const int') [-Werror,-Wfloat-conversion]
            static_cast<NewRep>(detail::apply_magnitude(static_cast<Common>(value_), Factor{})));
                                                        ~~~~~~~~~~~         ^~~~~~
au/quantity_test.cc:528:22: note: in instantiation of function template specialization 'au::Quantity<au::Feet, double>::as<std::complex<int>, au::QuantityMaker<au::Miles>, void>' requested here
    const auto b = a.as<std::complex<int>>(miles);
                     ^
1 error generated.

[CLAassistant]

All committers have signed the CLA.

[chiphogg]

What a subtle and tricky error! Thanks for root causing it and fixing it.

[chiphogg]

This whole implementation will get a lot cleaner once the #387 tsunami (not yet out for review) lands. It'll be back to just 1 line of code in this file. And it'll be simpler on the implementation side, too: it will generate exactly the static_cast calls that we need, and no others. (That set of static_cast calls will change slightly based on what I'm learning from this PR, but that change will be trivially easy.)

In the meantime, we'll be calling an extra layer of static_cast here for most types. I'm fine with that because we're going to fast-follow with the improvement. Not to mention, I suspect the compiler will optimize it out anyway.

[matthew-reynolds]

Nice. I don't particularly love that this PR is necessary, but agreed, I also expect the performance impact to be minimal and I'm glad to hear this will be refactored soonish.