Make expression templates implicitly convert...

[jzmaddock]

to types that the number type will also convert to. Fixes: https://github.com/boostorg/multiprecision/issues/541.

[jzmaddock]

Only failure is a network issue, merging.

[afabri]

Is this already in boost 1.82 ?

[jzmaddock]

It is, however, this https://github.com/boostorg/multiprecision/pull/545 has already cropped up, and as I fear this is the tip of an iceberg shaped tricky problem, I'm contemplating pulling the fix from 1.82.

[lrineau]

This code does not compile with Boost-1.82 but compiled with previous versions. Is that related?

#include <boost/multiprecision/cpp_int.hpp>

using Rational = boost::multiprecision::cpp_rational;

template <typename N> struct Sqrt {
  Sqrt() {}
  Sqrt(N) {}
  friend Sqrt<N> operator*(const Sqrt<N>& x, const Sqrt<N>&) { return x;}
  friend Sqrt<N> operator*(const N&, const Sqrt<N>& x) { return x;}
};

int main() {
  Rational r;
  Sqrt<Rational> s;

  Rational(r - r) * s;
  Sqrt<Rational> toto(r - r);
  Sqrt<Rational>(r - r) * s;
  (r - r) * s;  // ambiguous call to `operator*` here
}

[jzmaddock]

Yes, confirmed.

I've asked for permission to pull this fix from 1.82. It may even be that the issue is basically unfixable :(

[afabri]

It works for mpq_class which (we should double check) also uses expression templates.

[lrineau]

I agree this PR should be reverted. The class mpq_class from <gmpxx.h> does not has those operator T() to convert expression to everything. Instead their equivalent of number has non-explicit conversion constructors from the expression templates.

Since this PR, Boost MP expression templates are convertible to too many types, and that can lead to compilation errors with ambiguous calls (like https://github.com/boostorg/multiprecision/pull/543#issuecomment-1481575350).

[jzmaddock]

Reverted in develop and master.