Is it intended that Constructible<int&, long&>() is true?

[timsong-cpp]

__BindableReference is defined with a function-style cast expression, which is equivalent to a C-style cast in the single-argument case, which means it can degenerate to a reinterpret_cast or an access-bypassing static_cast.

Proposed Resolution

See P0547R1.

[timsong-cpp]

The definitions of CommonReference and Common also use function-style casts with single arguments and so may potentially have the same issue.

[ericniebler]

This is almost certainly a bug. These concepts need help. Having spent some time trying to implement a conforming std::is_constructible, I've come to appreciate just how difficult it is to get all the corner cases right. I suspect we'll need compiler help for Constructible, or else define it in terms of the std::is_constructible.

Another approach is to do what is_constructible does and define it in terms of the well-formed-ness of the statement T tmp(args...); for some invented variable tmp. That leaves it up to implementers as to how it should be implemented.

[ericniebler]

At the very least, we should change the proposed definition of __BindableReference to the version in cmcstl2:

template <class T, class... Args>
concept bool __BindableReference = // exposition only
  is_reference<T>::value && is_constructible<T, Args...>::value;
};

And once we take that step, it's a short hop to:

template <class T, class... Args>
concept bool Constructible() {
  return Destructible<T>() && is_constructible<T, Args...>::value;
}

This would require us to change Destructible to permit reference and array types. This version of Constructible no longer requires object types to be dynamically allocate-able. We could add that or live with it. (Where do we need that?) On the plus side, Constructible would now always subsume Destructible.

@CaseyCarter let's try to figure this one out for Kona.

[CaseyCarter]

CopyConstructible requires Constructible<T, const T&>(), which currently requires the expression T{ct} to be valid for an invented lvalue const T variable ct. CopyConstructible need not explicitly require Constructible<T, T&>() and/or Constructible<T, const T&&>() since the expression T{ct} implicitly requires expression variants (per [concepts.lib.general.equality]/6) T{a} and T{b} to be valid for an invented lvalue T a and rvalue const T b. If the definition of Constructible changes to be "equivalent to is_constructible<...stuff...>" instead of using an expression requirement, then CopyConstructible will have to ensure those construction variants explicitly.