[libc++] error: call to constructor of 'std::complex<float>' is ambiguous

[amilendra]

#include <complex>

typedef std::complex<float> Fcx;

struct S {
    S() {}
    S(const S&) {}
    template <class T> operator T() { return 0; }
} s;

int main(void)
{
    std::complex<float> *p00 = new std::complex<float>(s, s);
}

This program is accepted by libstdc++ but rejected by libc++

<source>:13:36: error: call to constructor of 'std::complex<float>' is ambiguous
   13 |     std::complex<float> *p00 = new std::complex<float>(s, s);
      |                                    ^                   ~~~~
/opt/compiler-explorer/clang-trunk-20240805/bin/../include/c++/v1/complex:422:43: note: candidate constructor
  422 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR complex(float __re = 0.0f, float __im = 0.0f) : __re_(__re), __im_(__im) {}
      |                                           ^
/opt/compiler-explorer/clang-trunk-20240805/bin/../include/c++/v1/complex:424:43: note: candidate constructor
  424 |   _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR complex(__from_builtin_tag, _Complex float __v)
      |                                           ^
1 error generated.
Compiler returned: 1

https://godbolt.org/z/6Ph1W7bq5
We found this from a downstream C++ library comparison test.

I think this is due to merge #83575
Would someone please have a look?

[MitalAshok]

Current libc++ behaviour seems to go against [member.functions]p2

For a non-virtual member function described in the C++ standard library, an implementation may declare a different set of member function signatures, provided that any call to the member function that would select an overload from the set of declarations described in this document behaves as if that overload were selected.

---

Similar problem with std::optional's tagged constructor (

llvm-project/libcxx/include/optional

Lines 303 to 306 in dc95aa2

	template <class _Fp, class... _Args>
	_LIBCPP_HIDE_FROM_ABI constexpr __optional_destruct_base(
	__optional_construct_from_invoke_tag, _Fp&& __f, _Args&&... __args)
	: __val_(std::invoke(std::forward<_Fp>(__f), std::forward<_Args>(__args)...)), __engaged_(true) {}

): https://godbolt.org/z/q1jjnWa6G

#include <optional>

struct X {
    template <class T> operator T();
};

int main() {
    std::optional<int> x(X{}, 0);  // Intended: `X{}.operator std::in_place_t()`
}

---

For std::optional, this can be avoided by not inheriting this constructor. That's not really an option for std::complex since the layout is important.

For std::complex there could be a static function static complex __from_builtin(_Complex T __v) { return complex(__real__ __v, __imag__ __v); } instead of a tagged constructor.

Something that could be done with all tagged constructors is instead of:

class_name(__tag_type, ...);

Have:

template<typename _Tag, __enable_if_t<is_same<_Tag, __tag_type>::value, int> = 0>
explicit class_name(_Tag, ...)

[androm3da]

We found this from a downstream C++ library comparison test.

I can confirm that I also have encountered this defect - (also while running a downstream conformance suite).

[frederick-vs-ja]

For the complex-specific case, I guess we can __bit_cast between std::complex and _Complex. Edit: Oops, it's not yet possible due to #94620.

[androm3da]

FYI @philnik777

[efriedma-quic]

Is anyone looking at this? It's a regression from 18 to 19.