P0415R1 constexpr For <complex> (Again)

[StephanTLavavej]

P0415R1 constexpr For <complex> (Again)

Feature-test macro after LWG-3349 was accepted:
#define __cpp_lib_constexpr_complex 201711L

As Daniil Goncharov (@Neargye) observed below, due to the NaN interactions, this depends on #22 WG21-P0476 <bit> bit_cast.

[Neargye]

First look at the issues:

0. operator/ call -> operator/= call -> _Div(...).
1. Division operations require IsNan/Nan. (Example for float)

    template <class _Other>
    _CONSTEXPR20 void _Div(const complex<_Other>& _Right) {
        using _Myctraits = _Ctraits<_Ty>;

        _Ty _Rightreal = static_cast<_Ty>(_Right.real());
        _Ty _Rightimag = static_cast<_Ty>(_Right.imag());

        if (_Myctraits::_Isnan(_Rightreal) || _Myctraits::_Isnan(_Rightimag)) { // <========
...
            if (_Myctraits::_Isnan(_Wd) || _Wd == 0) {
                this->_Val[_RE] = _Myctraits::_Nanv(); // <========
...
    }

2. Let's look at _Isnan. (Example for float)

    static bool _Isnan(_Ty _Left) {
        return _CSTD _FDtest(&_Left) == _NANCODE;
    }

3. And look at _FDtest. (Example for float)

_CRTIMP2_PURE short __CLRCALL_PURE_OR_CDECL _FDtest(float*);

At first glance, I didn't notice a neat way to add a modifier constexpr without breaking the logic of the code.

[StephanTLavavej]

Thanks for looking into this. We've had access to constexpr NaN for a while (see numeric_limits). For _Isnan, it looks like we'll need to use constexpr bit_cast(), after which the NaN pattern can be easily identified. So I'll add a note that this depends on #22.

[Neargye]

Ok, will try implement this.