[ 2025-08-29; Reflector poll ]

Set priority to 3 after reflector poll.

[member.functions]/2 seems to allow that even when the constraints are not met, such a default constructor can be selected, because no restriction is imposed when no overload is originally selected. Per the discussion in LWG 2563 (closed as NAD), it even seems to allow the implementation to add a default constructor when there's originally none.

However, we're constraining some member functions, e.g. default constructors of `unique_ptr`, `tuple`, and `variant`. Allowance of more permissive overload sets of constructors effectively renders the Constraints meaningless, because even if the implementation doesn't constrain the default constructors at all, it can still satisfy the restriction in [member.functions]/2 since LWG 2259.

Consider the following example:

struct S 
{
  S() = delete;
};

static_assert(std::is_default_constructible_v<std::tuple<S>>);
std::tuple<S> t;

Even though currently the default constructor of `std::tuple` is constrained ([tuple.cnstr]/6), [member.functions]/2 seemingly allows the implementation to add another overload that's also a default constructor, constrained by "is_default_constructible_v<T_i> is `false` for at least one i", and then render the example well-formed or only error on actual instantiation of the "additional" default constructor. Note that such an additional overload effectively removes the Constraints element requirements.

As shown by the example, the allowance in [member.functions]/2 can weaken or even invalidate Constraints of member functions.

So perhaps some wording change is necessary to guarantee the Constraints of member functions to be meaningful.