[libc++] Clean up pair's constructors and assignment operators

[ldionne]

Summary

This patch makes std::pair's constructors and assignment operators
closer to conforming in C++23. The only missing bit I am aware of
now is reference_constructs_from_temporary_v checks, which we
don't have the tools for yet.

This patch also refactors a long-standing non-standard extension where
we'd provide constructors for tuple-like types in all standard modes. The
criteria for being a tuple-like type are different from pair-like types
as introduced recently in the standard, leading to a lot of complexity
when trying to implement recent papers that touch the pair constructors.

After this patch, the pre-C++23 extension is provided in a self-contained
block so that we can easily deprecate and eventually remove the extension
in future releases.

[ldionne]

Pinging vendors since this is technically a source break. I'll also take this for a run internally to see how much breakage this causes, if any.

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv.pass.cpp

81

@huixie90 @tcanens

While implementing this, I found out that stuff like this would compile just fine:

std::pair<long, std::string> p;
p = std::tuple<long, float>{};

This is because std::string can be assigned-to from float. While this has nothing to do with pair specifically, this seems completely bonkers to me -- this is almost Javascript bad. I'm curious to know whether that has been discussed and acknowledged?

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

58

@tcanens @huixie90

This behavior seems to be inconsistent with the non-const-qualified operator= from pair-like. For operator=(PairLike) (not const), it seems like we go through subrange's operator pair-like(), which makes this work. But with operator=(pair-like) const, it looks like this conversion doesn't trigger and we end up not being able to perform the assignment. Does that match the LWG design intent?

[tcanens]

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv.pass.cpp

81

See https://cplusplus.github.io/LWG/issue3311 and the duplicate.

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

58

It doesn't trigger because ConstAssignable is not convertible from int*? Are the const/non-const cases actually different?

IIRC the constraint is there to prevent bypassing the slicing check on subrange's operator pair-like.

[rupprecht]

In D143914#4123012, @ldionne wrote:

Pinging vendors since this is technically a source break. I'll also take this for a run internally to see how much breakage this causes, if any.

This one is a bit bigger of a breakage for us. Do you have a target date for landing this patch?

[ldionne]

In D143914#4123385, @rupprecht wrote:

In D143914#4123012, @ldionne wrote:

Pinging vendors since this is technically a source break. I'll also take this for a run internally to see how much breakage this causes, if any.

This one is a bit bigger of a breakage for us. Do you have a target date for landing this patch?

I'd like to do it before the LLVM 17 release, and ideally not too late in the cycle to allow everyone to see this breakage well in advance. How bad is it?

[Mordante]

I mainly glossed over the code. I like to do a review with a paper or is this the exact wording in the current WP?

libcxx/include/__utility/pair.h

65

Does this patch complete a paper/LWG issue?

135

Would it be hard to keep these removed parts optionally available when using C++ < 23?
If so we could do our normal deprecation method.

For me it's not a blocker if it's too hard.

[ldionne]

In D143914#4123632, @Mordante wrote:

I mainly glossed over the code. I like to do a review with a paper or is this the exact wording in the current WP?

This is the wording in the current draft, modulo the reference_constructs_from_temporary bits. I had to do a full survey of what we do implement and what we didn't implement in various standard modes to try and come up with this.

libcxx/include/__utility/pair.h

65

In itself, no. It is preparing the terrain for being able to resolve P2255. That was originally my goal, in fact, and then I had to go down the rabbit hole when I saw that our pair constructors and assignment operators were not conforming at all.

135

Our usual deprecation method is to write it in the release notes, however in this case I am not sure how helpful that would be -- I doubt a lot of users read it and this extension has been there so long that it is probably taken for granted. Unless it breaks an unreasonable amount of code, IMO we should just go for it, it's not worse than a bunch of other fixes we've done in the past.

The other downside with deprecating this is that we'd now have a behavior that works in C++11/C++14/C++17/C++20 but is deprecated, and a subtly different non-deprecated behavior in C++23. As a user, I think I would find this rather confusing.

Before deciding to add complexity around this, I'd like to see how bad this is in real world code bases -- I'm waiting on Google's feedback here and I also started internal builds 105406484&105406488&105406497 (for my own ref).

[rupprecht]

In D143914#4123629, @ldionne wrote:

In D143914#4123385, @rupprecht wrote:

In D143914#4123012, @ldionne wrote:

Pinging vendors since this is technically a source break. I'll also take this for a run internally to see how much breakage this causes, if any.

This one is a bit bigger of a breakage for us. Do you have a target date for landing this patch?

I'd like to do it before the LLVM 17 release, and ideally not too late in the cycle to allow everyone to see this breakage well in advance. How bad is it?

Oh, it's not nearly that bad -- I meant if you were trying to land this in the next day or two :)

My initial sample-based test found 15 breakages. I'll know later how many actual breakages there are.

[rupprecht]

Still chugging away, looks like this is going to be at least 50 breakages. Most of them are trivial to fix (e.g. return std::make_tuple() in a method returning std::pair should be return std::make_pair()). There are a few that are a little surprising, such as this one which doesn't seem related to tuple compatibility:

void func() {
  std::map<unsigned long, std::string> m;

  // OK
  std::vector<std::pair<unsigned long, std::string>> v1(m.begin(), m.end());

  // OK before, but now: error: no matching constructor for initialization
  std::vector<
      std::pair<const unsigned long, std::reference_wrapper<std::string>>>
      v2(m.begin(), m.end());
}

With the full backtrace:

D143914.cc:14:7: error: no matching constructor for initialization of 'std::vector<std::pair<const unsigned long, std::reference_wrapper<std::string>>>' (aka 'vector<pair<const unsigned long, reference_wrapper<basic_string<char>>>>')
      v2(m.begin(), m.end());
      ^  ~~~~~~~~~~~~~~~~~~
vector:393:66: note: candidate constructor not viable: no known conversion from 'iterator' (aka '__map_iterator<__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>') to 'size_type' (aka 'unsigned long') for 1st argument
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI explicit vector(size_type __n, const allocator_type& __a);
                                                                 ^
vector:395:57: note: candidate constructor not viable: no known conversion from 'iterator' (aka '__map_iterator<__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>') to 'size_type' (aka 'unsigned long') for 1st argument
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI vector(size_type __n, const value_type& __x);
                                                        ^
vector:463:57: note: candidate constructor not viable: no known conversion from 'iterator' (aka '__map_iterator<__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>') to 'const vector<pair<const unsigned long, reference_wrapper<string>>>' for 1st argument
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI vector(const vector& __x, const __type_identity_t<allocator_type>& __a);
                                                        ^
vector:472:5: note: candidate constructor not viable: no known conversion from 'iterator' (aka '__map_iterator<__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>') to 'initializer_list<value_type>' (aka 'initializer_list<std::pair<const unsigned long, std::reference_wrapper<std::string>>>') for 1st argument
    vector(initializer_list<value_type> __il, const allocator_type& __a);
    ^
vector:488:5: note: candidate constructor not viable: no known conversion from 'iterator' (aka '__map_iterator<__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>') to 'vector<pair<const unsigned long, reference_wrapper<string>>>' for 1st argument
    vector(vector&& __x, const __type_identity_t<allocator_type>& __a);
    ^
vector:414:55: note: candidate template ignored: requirement '__is_exactly_cpp17_input_iterator<std::__map_iterator<std::__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>>::value' was not satisfied [with _InputIterator = iterator]
  _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI vector(_InputIterator __first, _InputIterator __last);
                                                      ^
vector:427:55: note: candidate template ignored: requirement 'is_constructible<std::pair<const unsigned long, std::reference_wrapper<std::string>>, std::pair<const unsigned long, std::string> &>::value' was not satisfied [with _ForwardIterator = iterator]
  _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI vector(_ForwardIterator __first, _ForwardIterator __last);
                                                      ^
vector:381:66: note: candidate constructor not viable: requires single argument '__a', but 2 arguments were provided
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI explicit vector(const allocator_type& __a)
                                                                 ^
vector:391:66: note: candidate constructor not viable: requires single argument '__n', but 2 arguments were provided
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI explicit vector(size_type __n);
                                                                 ^
vector:462:57: note: candidate constructor not viable: requires single argument '__x', but 2 arguments were provided
    _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI vector(const vector& __x);
                                                        ^
vector:469:5: note: candidate constructor not viable: requires single argument '__il', but 2 arguments were provided
    vector(initializer_list<value_type> __il);
    ^
vector:480:5: note: candidate constructor not viable: requires single argument '__x', but 2 arguments were provided
    vector(vector&& __x)
    ^
vector:399:5: note: candidate constructor template not viable: requires 3 arguments, but 2 were provided
    vector(size_type __n, const value_type& __x, const allocator_type& __a)
    ^
vector:420:3: note: candidate constructor template not viable: requires 3 arguments, but 2 were provided
  vector(_InputIterator __first, _InputIterator __last, const allocator_type& __a);
  ^
vector:434:3: note: candidate constructor template not viable: requires 3 arguments, but 2 were provided
  vector(_ForwardIterator __first, _ForwardIterator __last, const allocator_type& __a);
  ^
vector:377:5: note: candidate constructor not viable: requires 0 arguments, but 2 were provided
    vector() _NOEXCEPT_(is_nothrow_default_constructible<allocator_type>::value)
    ^

[rupprecht]

The only other breakage I found so far that might be worthy of mention is that constructing containers requires begin/end iterators of pairs, not tuples, but frameworks for doing functional-style programming often tuples to be fully generic, so this breaks. This seems like an intended effect of this patch, but makes things a little less ergonomic. Is there an idiomatic way to do that w/o having to write your own tuple->pair boilerplate?

void func2() {
  std::vector<int> v1 = {1, 2, 3};
  std::vector<std::string> v2 = {"One", "Two", "Three"};

  // Using a framework like https://github.com/ryanhaining/cppitertools
  auto v = iter::zip(v1, v2);  // Elements are `tuple<int &, std::string &>`

  // std::map constructor accepts iterator<pair>, not iterator<tuple>, so this no longer works
  std::map<int, std::string> m(v.begin(), v.end());

  // Now mapping it to pairs is required:
  auto v_pairs =
      v | iter::imap([](const auto& tuple) {
        return std::make_pair(std::get<0>(tuple), std::get<1>(tuple));
      });
  // OK
  std::map<int, std::string> m2(v_pairs.begin(), v_pairs.end());
}

[ldionne]

In D143914#4125054, @rupprecht wrote:

The only other breakage I found so far that might be worthy of mention is that constructing containers requires begin/end iterators of pairs, not tuples, but frameworks for doing functional-style programming often tuples to be fully generic, so this breaks. This seems like an intended effect of this patch, but makes things a little less ergonomic. Is there an idiomatic way to do that w/o having to write your own tuple->pair boilerplate?

Switching to -std=c++2b would fix that -- IMO that sounds reasonable but I am interested to know if you disagree.

Thanks a lot for the back and forth here, this is invaluable. I will take a look at the vector issue when I have a bit of time.

I would recommend you get started on fixing the obvious ones at least, but this is probably going to be paused for ~2 weeks since I'll go OOO next week.

[rupprecht]

In D143914#4127330, @ldionne wrote:

In D143914#4125054, @rupprecht wrote:

The only other breakage I found so far that might be worthy of mention is that constructing containers requires begin/end iterators of pairs, not tuples, but frameworks for doing functional-style programming often tuples to be fully generic, so this breaks. This seems like an intended effect of this patch, but makes things a little less ergonomic. Is there an idiomatic way to do that w/o having to write your own tuple->pair boilerplate?

Switching to -std=c++2b would fix that -- IMO that sounds reasonable but I am interested to know if you disagree.

It isn't an option for us, but I don't think it's worth it to keep a non-conformant extension + complexity in libc++ just so we can avoid a little boilerplate to do tuple->pair manually in a couple places.

Thanks a lot for the back and forth here, this is invaluable. I will take a look at the vector issue when I have a bit of time.

I would recommend you get started on fixing the obvious ones at least, but this is probably going to be paused for ~2 weeks since I'll go OOO next week.

Sounds good, that timeline should work. Have a good break!

[hans]

In D143914#4123012, @ldionne wrote:

Pinging vendors since this is technically a source break.

I didn't hit any issues with this in Chromium (Linux and Windows).

[Mordante]

libcxx/include/__utility/pair.h

65

I know the feeling of the rabbit hole :-/

135

Sound fine to me, just wanted to make sure it's a deliberate choice.

325–326

IIRC the style using an int is the preferred style. Feel free to ignore it when I'm wrong.

[huixie90]

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

58

speaking of subrange, I think it is worth adding more tests such as

Pair p = subrange1;
Pair p{subrange1};
auto p = static_cast<Pair>(subrange);

where the pair's constructor and subrange's conversion operator both can work.
(apparently subrange's conversion operator is more constrained than pair's constructor but I think that does not change anything?)

[ldionne]

In D143914#4124996, @rupprecht wrote:

Still chugging away, looks like this is going to be at least 50 breakages. Most of them are trivial to fix (e.g. return std::make_tuple() in a method returning std::pair should be return std::make_pair()). There are a few that are a little surprising, such as this one which doesn't seem related to tuple compatibility:

void func() {
  std::map<unsigned long, std::string> m;

  // OK
  std::vector<std::pair<unsigned long, std::string>> v1(m.begin(), m.end());

  // OK before, but now: error: no matching constructor for initialization
  std::vector<
      std::pair<const unsigned long, std::reference_wrapper<std::string>>>
      v2(m.begin(), m.end());
}

This seems to be the relevant part:

include/c++/v1/vector:427:55: note: candidate template ignored: requirement 'is_constructible<std::pair<const unsigned long, std::reference_wrapper<std::string>>, std::pair<const unsigned long, std::string> &>::value' was not satisfied [with _ForwardIterator = std::__map_iterator<std::__tree_iterator<std::__value_type<unsigned long, std::string>, std::__tree_node<std::__value_type<unsigned long, std::string>, void *> *, long>>]
  _LIBCPP_CONSTEXPR_SINCE_CXX20 _LIBCPP_HIDE_FROM_ABI vector(_ForwardIterator __first, _ForwardIterator __last);
                                                      ^

It basically boils down to this:

#include <map>
#include <string>
#include <type_traits>
#include <utility>
#include <vector>

int main(int, char**) {
  std::map<unsigned long, std::string> m;

  // OK
  using Pair1 = std::pair<unsigned long, std::string>;
  std::vector<Pair1> v1(m.begin(), m.end());

  // OK before, but not anymore
  using Pair2 = std::pair<const unsigned long, std::reference_wrapper<std::string>>;
  static_assert(std::is_constructible_v<Pair2, std::pair<const unsigned long, std::string> &>);
}

This used to be accepted by libc++ but isn't anymore. This was never accepted by other standard libraries though: https://godbolt.org/z/c4svx1YTG.

Incidentally, checking for static_assert(std::is_constructible_v<Pair2, std::pair<const unsigned long, std::string> const&>); instead (notice I made the right hand side a const&) never works, on all stdlib implementations: https://godbolt.org/z/M8odqfvKM.

Hence, I'd argue this is somewhat brittle and I think this is both a corner case and also something that I'd be fine with breaking. Thoughts?

So, for the next steps:

1. I want to get the subrange operator= const vs operator= situation understood
2. I got back our internal build results and I did see a few failures similar to what @rupprecht saw. I think this will bite a few users, however the fix in most cases should be to use -std=c++2b and the code will work out of the box. None of these failures seemed too hard to fix.

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

58

@tcanens

It doesn't trigger because ConstAssignable is not convertible from int*

Ah, yes, obviously that's *one* problem. But even after fixing it, the behavior for const and non-const is different AFAICT:

// const assignment
struct ConstAssignable {
  mutable int* ptr = nullptr;
  ConstAssignable() = default;
  constexpr ConstAssignable(int* p) : ptr(p) { } // enable `subrange::operator pair-like`
  constexpr ConstAssignable const& operator=(int* p) const { ptr = p; return *this; }
};

static_assert( std::is_assignable_v<std::pair<ConstAssignable, ConstAssignable> const&, std::tuple<int*, int*>>); // test the test
static_assert(!std::is_assignable_v<std::pair<ConstAssignable, ConstAssignable> const&, std::ranges::subrange<int*>>);

// non-const assignment
struct Assignable {
  int* ptr = nullptr;
  Assignable() = default;
  constexpr Assignable(int* p) : ptr(p) { } // enable `subrange::operator pair-like`
  constexpr Assignable& operator=(int* p) { ptr = p; return *this; }
};
int data[] = {1, 2, 3, 4, 5};
std::ranges::subrange<int*> a(data);
std::pair<Assignable, Assignable> p;
p = a; // that's fine

Did I miss something else here? There must be something else going on that causes the operator pair-like for std::subrange to not trigger when the elements are const-assignable but not "just" assignable. Honestly, I am left wondering whether a const operator= triggers the same sequence of implicit conversions than the non-const operator=.

[tcanens]

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

58

The difference is that ConstAssignable isn't const-assignable from ConstAssignable (but Assignable is assignable from Assignable).

operator pair-like converts the subrange to a std::pair<ConstAssignable, ConstAssignable> (or std::pair<Assignable, Assignable>) and the assignment is performed from that, so you need const-assignment from ConstAssignable`, not int*.

[jyknight]

however the fix in most cases should be to use -std=c++2b and the code will work out of the box.

It was unfortunate that libc++ shipped this extension in the first place, but given that it did, it seems a little weird to require all users to migrate away from using the long-standing extension, only to bring it (mostly) right back in C++23 mode.

I wonder if it'd make sense to keep the extension in earlier standards modes, but modified to have the C++23 requirements. I'm assuming that the differences between the previous "tuple-like" requirement and new "pair-like" requirement is likely to be irrelevant to the real-world usages -- maybe worth verifying that assumption?

[rupprecht]

The total impact for us is ~400 files, but very trivial in most cases, and usually only a couple impacted lines per file.

AFAICT, the breakage is entirely internal. I haven't found a single breakage in any external code. There could be any number of reasons to explain this, but generally speaking I would expect this to not have a broad impact -- the large breakage we see is probably the outlier.

I don't have a personal opinion whether this is good to land, as I can see arguments either way. I'd still like some time to continue cleaning things up -- 2-3 weeks is likely good enough to get most if not all of it done.

In D143914#4136705, @ldionne wrote:

This used to be accepted by libc++ but isn't anymore. This was never accepted by other standard libraries though: https://godbolt.org/z/c4svx1YTG.

Incidentally, checking for static_assert(std::is_constructible_v<Pair2, std::pair<const unsigned long, std::string> const&>); instead (notice I made the right hand side a const&) never works, on all stdlib implementations: https://godbolt.org/z/M8odqfvKM.

Hence, I'd argue this is somewhat brittle and I think this is both a corner case and also something that I'd be fine with breaking. Thoughts?

I'm fine accepting this outcome, but OOC, do you know why it's (erroneously) being accepted prior to this patch? Is it doing an implicit conversion roundtrip through something like pair<T, U> -> tuple<T, U> -> pair<const T, std::reference_wrapper<U>>?

[ldionne]

In D143914#4145669, @jyknight wrote:

I wonder if it'd make sense to keep the extension in earlier standards modes, but modified to have the C++23 requirements.

Instead, here's what I suggest: I refactored the extension so that it would be self-contained in a separate set of constructors and assignment operators. That way, it's mostly out of the way for implementing the actual standard-specified constructors and assignment operators.

As it stands, this patch should not be a source break in most cases. There might be a few tiny cases where the new conversions will behave unlike the old conversions, but it should more or less work out of the box. I suggest that we then mark these extensions as deprecated with a message telling users to move to C++23 to get this behavior, and then remove the extensions in a future release. That will provide a better experience for folks.

libcxx/include/__utility/pair.h

325–326

We use nullptr elsewhere in pair.h, so I'll stick to that.

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv.pass.cpp

81

Thanks for the pointer!

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

58

Ah, of course, thanks!

[ldionne]

Rebase, reintroduce extension pre C++23.

[ldionne]

Fix C++03

[ldionne]

@rupprecht This version of the patch should significantly reduce the number of small failures you're seeing due to tuple/array/pair incompatibilities. Would you be able to confirm that this is landable as far as you're concerned?

[ldionne]

Add missing include

[ldionne]

Fix some GCC issues.

[ldionne]

Add missing includes

[ldionne]

@rupprecht I'd like to land this within the next few days. If you're able to confirm that this doesn't cause as many issues for you anymore, that would be great. Otherwise, i'll land this without your confirmation -- I am fairly confident this new patch should solve the vast majority of issues you were seeing.

[rupprecht]

In D143914#4292303, @ldionne wrote:

@rupprecht I'd like to land this within the next few days. If you're able to confirm that this doesn't cause as many issues for you anymore, that would be great. Otherwise, i'll land this without your confirmation -- I am fairly confident this new patch should solve the vast majority of issues you were seeing.

Sorry, I've been out for a few days. Indeed, the impact seems much smaller.

The one breakage I found so far is:

std::vector<std::pair<int, Foo>> foo_pairs;
for (std::pair<int, Foo&> foo : foo_pairs) {...}

I expect not many breakages, so I'm fine with this landing. Thanks for checking in.

[ldionne]

Awesome, let's do this then!

libcxx/include/__tuple/sfinae_helpers.h

 
 
 template <size_t _Ip, class ..._Tp>
 struct _LIBCPP_TEMPLATE_VIS tuple_element<_Ip, tuple<_Tp...> >
 {
     typedef _LIBCPP_NODEBUG typename tuple_element<_Ip, __tuple_types<_Tp...> >::type type;
 };
 
-template <bool _IsTuple, class _SizeTrait, size_t _Expected>
-struct __tuple_like_with_size_imp : false_type {};
-
-template <class _SizeTrait, size_t _Expected>
-struct __tuple_like_with_size_imp<true, _SizeTrait, _Expected>
-    : integral_constant<bool, _SizeTrait::value == _Expected> {};
-
-template <class _Tuple, size_t _ExpectedSize, class _RawTuple = __libcpp_remove_reference_t<_Tuple> >
-using __tuple_like_with_size _LIBCPP_NODEBUG = __tuple_like_with_size_imp<
-                                   __tuple_like_ext<_RawTuple>::value,
-                                   tuple_size<_RawTuple>, _ExpectedSize
-                              >;
-
 struct _LIBCPP_TYPE_VIS __check_tuple_constructor_fail {
 
     static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_explicit_default() { return false; }
     static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_implicit_default() { return false; }
     template <class ...>
     static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_explicit() { return false; }
     template <class ...>
     static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_implicit() { return false; }

libcxx/include/__utility/pair.h

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef _LIBCPP___UTILITY_PAIR_H
 #define _LIBCPP___UTILITY_PAIR_H
 
 #include <__compare/common_comparison_category.h>
 #include <__compare/synth_three_way.h>
+#include <__concepts/different_from.h>
 #include <__config>
 #include <__functional/unwrap_ref.h>
 #include <__fwd/get.h>
+#include <__fwd/subrange.h>
 #include <__fwd/tuple.h>
+#include <__tuple/pair_like.h>
 #include <__tuple/sfinae_helpers.h>
 #include <__tuple/tuple_element.h>
 #include <__tuple/tuple_indices.h>
 #include <__tuple/tuple_size.h>
 #include <__type_traits/common_reference.h>
 #include <__type_traits/common_type.h>
 #include <__type_traits/conditional.h>
 #include <__type_traits/decay.h>
+#include <__type_traits/integral_constant.h>
 #include <__type_traits/is_assignable.h>
 #include <__type_traits/is_constructible.h>
 #include <__type_traits/is_convertible.h>
 #include <__type_traits/is_copy_assignable.h>
 #include <__type_traits/is_default_constructible.h>
 #include <__type_traits/is_implicitly_default_constructible.h>
 #include <__type_traits/is_move_assignable.h>
 #include <__type_traits/is_nothrow_assignable.h>

 template <class, class>
 struct __non_trivially_copyable_base {
   _LIBCPP_CONSTEXPR _LIBCPP_HIDE_FROM_ABI
   __non_trivially_copyable_base() _NOEXCEPT {}
   _LIBCPP_CONSTEXPR_SINCE_CXX14 _LIBCPP_HIDE_FROM_ABI
   __non_trivially_copyable_base(__non_trivially_copyable_base const&) _NOEXCEPT {}
 };
 
+#if _LIBCPP_STD_VER >= 23
+template <class _Tp>
+struct __is_specialization_of_subrange : false_type {};
+
+template <class _Iter, class _Sent, ranges::subrange_kind _Kind>
+struct __is_specialization_of_subrange<ranges::subrange<_Iter, _Sent, _Kind>> : true_type {};
+#endif
+
 template <class _T1, class _T2>
 struct _LIBCPP_TEMPLATE_VIS pair
 #if defined(_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR)
 : private __non_trivially_copyable_base<_T1, _T2>
 #endif
 {
     using first_type = _T1;
     using second_type = _T2;
struct _CheckArgs {
           return __is_pair_constructible<_U1, _U2>() && __is_implicit<_U1, _U2>();
       }
     };
 
     template <bool _MaybeEnable>
     using _CheckArgsDep _LIBCPP_NODEBUG = typename conditional<
       _MaybeEnable, _CheckArgs, __check_tuple_constructor_fail>::type;
 
-    struct _CheckTupleLikeConstructor {
-        template <class _Tuple>
-        static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_implicit() {
-            return __tuple_convertible<_Tuple, pair>::value;
-        }
-
-        template <class _Tuple>
-        static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_explicit() {
-            return __tuple_constructible<_Tuple, pair>::value
-               && !__tuple_convertible<_Tuple, pair>::value;
-        }
-
-        template <class _Tuple>
-        static _LIBCPP_HIDE_FROM_ABI constexpr bool __enable_assign() {
-            return __tuple_assignable<_Tuple, pair>::value;
-        }
-    };
-
-    template <class _Tuple>
-    using _CheckTLC _LIBCPP_NODEBUG = __conditional_t<
-        __tuple_like_with_size<_Tuple, 2>::value
-            && !is_same<__decay_t<_Tuple>, pair>::value,
-        _CheckTupleLikeConstructor,
-        __check_tuple_constructor_fail
-    >;
-
     template<bool _Dummy = true, typename enable_if<
             _CheckArgsDep<_Dummy>::__enable_explicit_default()
     >::type* = nullptr>
     explicit _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR
     pair() _NOEXCEPT_(is_nothrow_default_constructible<first_type>::value &&
                       is_nothrow_default_constructible<second_type>::value)
         : first(), second() {}
 
#if _LIBCPP_STD_VER >= 23
     _LIBCPP_HIDE_FROM_ABI constexpr
     explicit(!_CheckArgs::template __is_implicit<const _U1&&, const _U2&&>())
     pair(const pair<_U1, _U2>&& __p)
         noexcept(is_nothrow_constructible<first_type, const _U1&&>::value &&
                  is_nothrow_constructible<second_type, const _U2&&>::value)
         : first(std::move(__p.first)), second(std::move(__p.second)) {}
 #endif
 
-    template<class _Tuple, typename enable_if<
-            _CheckTLC<_Tuple>::template __enable_explicit<_Tuple>()
-    >::type* = nullptr>
-    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
-    explicit pair(_Tuple&& __p)
-        : first(std::get<0>(std::forward<_Tuple>(__p))),
-          second(std::get<1>(std::forward<_Tuple>(__p))) {}
-
-    template<class _Tuple, typename enable_if<
-            _CheckTLC<_Tuple>::template __enable_implicit<_Tuple>()
-    >::type* = nullptr>
-    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
-    pair(_Tuple&& __p)
-        : first(std::get<0>(std::forward<_Tuple>(__p))),
-          second(std::get<1>(std::forward<_Tuple>(__p))) {}
+#  if _LIBCPP_STD_VER >= 23
+    // This is a workaround for http://llvm.org/PR60710. We should be able to remove it once Clang is fixed.
+    template <class _PairLike, bool _Enable = tuple_size<remove_cvref_t<_PairLike>>::value == 2>
+    _LIBCPP_HIDE_FROM_ABI static constexpr bool __pair_like_explicit_wknd() {
+        if constexpr (tuple_size<remove_cvref_t<_PairLike>>::value == 2) {
+            return !is_convertible_v<decltype(std::get<0>(std::declval<_PairLike&&>())), first_type> ||
+                   !is_convertible_v<decltype(std::get<1>(std::declval<_PairLike&&>())), second_type>;
+        }
+        return false;
+    }
+
+    template <__pair_like _PairLike>
+      requires(is_constructible_v<first_type, decltype(std::get<0>(std::declval<_PairLike&&>()))> &&
+               is_constructible_v<second_type, decltype(std::get<1>(std::declval<_PairLike&&>()))>)
+    _LIBCPP_HIDE_FROM_ABI constexpr explicit(__pair_like_explicit_wknd<_PairLike>())
+        pair(_PairLike&& __p)
+        : first(std::get<0>(std::forward<_PairLike>(__p))), second(std::get<1>(std::forward<_PairLike>(__p))) {}
+#  endif
 
     template <class... _Args1, class... _Args2>
     _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20
     pair(piecewise_construct_t __pc,
          tuple<_Args1...> __first_args, tuple<_Args2...> __second_args)
         _NOEXCEPT_((is_nothrow_constructible<first_type, _Args1...>::value &&
                     is_nothrow_constructible<second_type, _Args2...>::value))
         : pair(__pc, __first_args, __second_args,
pair& operator=(__conditional_t<
         _NOEXCEPT_(is_nothrow_move_assignable<first_type>::value &&
                    is_nothrow_move_assignable<second_type>::value)
     {
         first = std::forward<first_type>(__p.first);
         second = std::forward<second_type>(__p.second);
         return *this;
     }
 
-#if _LIBCPP_STD_VER >= 23
+    template <class _U1, class _U2, __enable_if_t<
+        is_assignable<first_type&, _U1 const&>::value &&
+        is_assignable<second_type&, _U2 const&>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20
+    pair& operator=(pair<_U1, _U2> const& __p) {
+        first = __p.first;
+        second = __p.second;
+        return *this;
+    }
+
+    template <class _U1, class _U2, __enable_if_t<
+        is_assignable<first_type&, _U1>::value &&
+        is_assignable<second_type&, _U2>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20
+    pair& operator=(pair<_U1, _U2>&& __p) {
+        first = std::forward<_U1>(__p.first);
+        second = std::forward<_U2>(__p.second);
+        return *this;
+    }
+
+#  if _LIBCPP_STD_VER >= 23
     _LIBCPP_HIDE_FROM_ABI constexpr
     const pair& operator=(pair const& __p) const
       noexcept(is_nothrow_copy_assignable_v<const first_type> &&
                is_nothrow_copy_assignable_v<const second_type>)
       requires(is_copy_assignable_v<const first_type> &&
                is_copy_assignable_v<const second_type>) {
         first = __p.first;
         second = __p.second;
#  if _LIBCPP_STD_VER >= 23
     _LIBCPP_HIDE_FROM_ABI constexpr
     const pair& operator=(pair<_U1, _U2>&& __p) const
       requires(is_assignable_v<const first_type&, _U1> &&
                is_assignable_v<const second_type&, _U2>) {
         first = std::forward<_U1>(__p.first);
         second = std::forward<_U2>(__p.second);
         return *this;
     }
-#endif // _LIBCPP_STD_VER >= 23
+
+    template <__pair_like _PairLike>
+      requires(__different_from<_PairLike, pair> &&
+               !__is_specialization_of_subrange<remove_cvref_t<_PairLike>>::value &&
+               is_assignable_v<first_type&, decltype(std::get<0>(std::declval<_PairLike>()))> &&
+               is_assignable_v<second_type&, decltype(std::get<1>(std::declval<_PairLike>()))>)
+    _LIBCPP_HIDE_FROM_ABI constexpr pair& operator=(_PairLike&& __p) {
+        first  = std::get<0>(std::forward<_PairLike>(__p));
+        second = std::get<1>(std::forward<_PairLike>(__p));
+        return *this;
+    }
+
+    template <__pair_like _PairLike>
+      requires(__different_from<_PairLike, pair> &&
+               !__is_specialization_of_subrange<remove_cvref_t<_PairLike>>::value &&
+               is_assignable_v<first_type const&, decltype(std::get<0>(std::declval<_PairLike>()))> &&
+               is_assignable_v<second_type const&, decltype(std::get<1>(std::declval<_PairLike>()))>)
+    _LIBCPP_HIDE_FROM_ABI constexpr pair const& operator=(_PairLike&& __p) const {
+        first  = std::get<0>(std::forward<_PairLike>(__p));
+        second = std::get<1>(std::forward<_PairLike>(__p));
+        return *this;
+    }
+#  endif // _LIBCPP_STD_VER >= 23
 
-    template <class _Tuple, typename enable_if<
-            _CheckTLC<_Tuple>::template __enable_assign<_Tuple>()
-     >::type* = nullptr>
-    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20
-    pair& operator=(_Tuple&& __p) {
-        first = std::get<0>(std::forward<_Tuple>(__p));
-        second = std::get<1>(std::forward<_Tuple>(__p));
+    // Prior to C++23, we provide an approximation of constructors and assignment operators from
+    // pair-like types. This was historically provided as an extension.
+#if _LIBCPP_STD_VER < 23
+    // from std::tuple
+    template<class _U1, class _U2, __enable_if_t<
+        is_convertible<_U1 const&, _T1>::value &&
+        is_convertible<_U2 const&, _T2>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair(tuple<_U1, _U2> const& __p)
+        : first(std::get<0>(__p)),
+          second(std::get<1>(__p)) {}
+
+    template<class _U1, class _U2, __enable_if_t<
+        is_constructible<_T1, _U1 const&>::value &&
+        is_constructible<_T2, _U2 const&>::value &&
+        !(is_convertible<_U1 const&, _T1>::value &&
+          is_convertible<_U2 const&, _T2>::value)
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    explicit
+    pair(tuple<_U1, _U2> const& __p)
+        : first(std::get<0>(__p)),
+          second(std::get<1>(__p)) {}
+
+    template<class _U1, class _U2, __enable_if_t<
+        is_convertible<_U1, _T1>::value &&
+        is_convertible<_U2, _T2>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair(tuple<_U1, _U2>&& __p)
+        : first(std::get<0>(std::move(__p))),
+          second(std::get<1>(std::move(__p))) {}
+
+    template<class _U1, class _U2, __enable_if_t<
+        is_constructible<_T1, _U1>::value &&
+        is_constructible<_T2, _U2>::value &&
+        !(is_convertible<_U1, _T1>::value &&
+          is_convertible<_U2, _T2>::value)
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    explicit
+    pair(tuple<_U1, _U2>&& __p)
+        : first(std::get<0>(std::move(__p))),
+          second(std::get<1>(std::move(__p))) {}
+
+
+    template<class _U1, class _U2, __enable_if_t<
+        is_assignable<_T1&, _U1 const&>::value &&
+        is_assignable<_T2&, _U2 const&>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair& operator=(tuple<_U1, _U2> const& __p) {
+        first = std::get<0>(__p);
+        second = std::get<1>(__p);
+        return *this;
+    }
+
+    template<class _U1, class _U2, __enable_if_t<
+        is_assignable<_T1&, _U1&&>::value &&
+        is_assignable<_T2&, _U2&&>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair& operator=(tuple<_U1, _U2>&& __p) {
+        first = std::get<0>(std::move(__p));
+        second = std::get<1>(std::move(__p));
+        return *this;
+    }
+
+    // from std::array
+    template<class _Up, __enable_if_t<
+        is_convertible<_Up const&, _T1>::value &&
+        is_convertible<_Up const&, _T2>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair(array<_Up, 2> const& __p)
+        : first(__p[0]),
+          second(__p[1]) {}
+
+    template<class _Up, __enable_if_t<
+        is_constructible<_T1, _Up const&>::value &&
+        is_constructible<_T2, _Up const&>::value &&
+        !(is_convertible<_Up const&, _T1>::value &&
+          is_convertible<_Up const&, _T2>::value)
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    explicit
+    pair(array<_Up, 2> const& __p)
+        : first(__p[0]),
+          second(__p[1]) {}
+
+    template<class _Up, __enable_if_t<
+        is_convertible<_Up, _T1>::value &&
+        is_convertible<_Up, _T2>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair(array<_Up, 2>&& __p)
+        : first(std::move(__p)[0]),
+          second(std::move(__p)[1]) {}
+
+    template<class _Up, __enable_if_t<
+        is_constructible<_T1, _Up>::value &&
+        is_constructible<_T2, _Up>::value &&
+        !(is_convertible<_Up, _T1>::value &&
+          is_convertible<_Up, _T2>::value)
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    explicit
+    pair(array<_Up, 2>&& __p)
+        : first(std::move(__p)[0]),
+          second(std::move(__p)[1]) {}
+
+
+    template<class _Up, __enable_if_t<
+        is_assignable<_T1&, _Up const&>::value &&
+        is_assignable<_T2&, _Up const&>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair& operator=(array<_Up, 2> const& __p) {
+        first = std::get<0>(__p);
+        second = std::get<1>(__p);
+        return *this;
+    }
+
+    template<class _Up, __enable_if_t<
+        is_assignable<_T1&, _Up>::value &&
+        is_assignable<_T2&, _Up>::value
+    >* = nullptr>
+    _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14
+    pair& operator=(array<_Up, 2>&& __p) {
+        first = std::get<0>(std::move(__p));
+        second = std::get<1>(std::move(__p));
         return *this;
     }
+#endif // _LIBCPP_STD_VER < 23
 #endif // _LIBCPP_CXX03_LANG
 
     _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20
     void
     swap(pair& __p) _NOEXCEPT_(__is_nothrow_swappable<first_type>::value &&
                                __is_nothrow_swappable<second_type>::value)
     {
         using std::swap;

libcxx/include/utility

struct pair
     T1 first;
     T2 second;
 
     pair(const pair&) = default;
     pair(pair&&) = default;
     explicit(see-below) constexpr pair();
     explicit(see-below) pair(const T1& x, const T2& y);                          // constexpr in C++14
     template <class U = T1, class V = T2> explicit(see-below) pair(U&&, V&&);    // constexpr in C++14
-    template <class U, class V> constexpr explicit(see below) pair(pair<U, V>&); // since C++23
+    template <class U, class V> constexpr explicit(see-below) pair(pair<U, V>&); // since C++23
     template <class U, class V> explicit(see-below) pair(const pair<U, V>& p);   // constexpr in C++14
     template <class U, class V> explicit(see-below) pair(pair<U, V>&& p);        // constexpr in C++14
     template <class U, class V>
-    constexpr explicit(see below) pair(const pair<U, V>&&);                      // since C++23
+    constexpr explicit(see-below) pair(const pair<U, V>&&);                      // since C++23
+    template <pair-like P> constexpr explicit(see-below) pair(P&&);              // since C++23
     template <class... Args1, class... Args2>
-        pair(piecewise_construct_t, tuple<Args1...> first_args,
-             tuple<Args2...> second_args);                                       // constexpr in C++20
+        pair(piecewise_construct_t, tuple<Args1...> first_args,                  // constexpr in C++20
+                                    tuple<Args2...> second_args);
 
     constexpr const pair& operator=(const pair& p) const;                        // since C++23
     template <class U, class V> pair& operator=(const pair<U, V>& p);            // constexpr in C++20
     template <class U, class V>
     constexpr const pair& operator=(const pair<U, V>& p) const;                  // since C++23
     pair& operator=(pair&& p) noexcept(is_nothrow_move_assignable<T1>::value &&
                                        is_nothrow_move_assignable<T2>::value);   // constexpr in C++20
     constexpr const pair& operator=(pair&& p) const;                             // since C++23
     template <class U, class V> pair& operator=(pair<U, V>&& p);                 // constexpr in C++20
     template <class U, class V>
     constexpr const pair& operator=(pair<U, V>&& p) const;                       // since C++23
+    template <pair-like P> constexpr pair& operator=(P&&);                       // since C++23
+    template <pair-like P> constexpr const pair& operator=(P&&) const;           // since C++23
 
     void swap(pair& p) noexcept(is_nothrow_swappable_v<T1> &&
                                 is_nothrow_swappable_v<T2>);                     // constexpr in C++20
     constexpr void swap(const pair& p) const noexcept(see below);                // since C++23
 };
 
 template<class T1, class T2, class U1, class U2, template<class> class TQual, template<class> class UQual>
 struct basic_common_reference<pair<T1, T2>, pair<U1, U2>, TQual, UQual>;         // since C++23

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv.pass.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17, c++20
+
+// <utility>
+
+// template <class T1, class T2> struct pair
+
+//  template <pair-like P> constexpr pair& operator=(P&&);  // since C++23
+
+#include <array>
+#include <cassert>
+#include <concepts>
+#include <ranges>
+#include <string>
+#include <tuple>
+#include <type_traits>
+#include <utility>
+
+constexpr bool test() {
+  // Make sure assignment works from array and tuple
+  {
+    // Check from std::array
+    {
+      std::array<int, 2> a = {1, 2};
+      std::pair<int, int> p;
+      std::same_as<std::pair<int, int>&> decltype(auto) result = (p = a);
+      assert(&result == &p);
+      assert(p.first == 1);
+      assert(p.second == 2);
+      static_assert(!std::is_assignable_v<std::pair<int, int>&, std::array<int, 1>>); // too small
+      static_assert( std::is_assignable_v<std::pair<int, int>&, std::array<int, 2>>); // works (test the test)
+      static_assert(!std::is_assignable_v<std::pair<int, int>&, std::array<int, 3>>); // too large
+    }
+
+    // Check from std::tuple
+    {
+      std::tuple<int, int> a = {1, 2};
+      std::pair<int, int> p;
+      std::same_as<std::pair<int, int>&> decltype(auto) result = (p = a);
+      assert(&result == &p);
+      assert(p.first == 1);
+      assert(p.second == 2);
+      static_assert(!std::is_assignable_v<std::pair<int, int>&, std::tuple<int>>); // too small
+      static_assert( std::is_assignable_v<std::pair<int, int>&, std::tuple<int, int>>); // works (test the test)
+      static_assert(!std::is_assignable_v<std::pair<int, int>&, std::tuple<int, int, int>>); // too large
+    }
+
+    // Make sure it works for ranges::subrange. This actually deserves an explanation: even though
+    // the assignment operator explicitly excludes ranges::subrange specializations, such assignments
+    // end up working because of ranges::subrange's implicit conversion to pair-like types.
+    // This test ensures that the interoperability works as intended.
+    {
+      struct Assignable {
+        int* ptr = nullptr;
+        Assignable() = default;
+        constexpr Assignable(int* p) : ptr(p) { } // enable `subrange::operator pair-like`
+        constexpr Assignable& operator=(Assignable const&) = default;
+      };
+      int data[] = {1, 2, 3, 4, 5};
+      std::ranges::subrange<int*> a(data);
+      std::pair<Assignable, Assignable> p;
+      std::same_as<std::pair<Assignable, Assignable>&> decltype(auto) result = (p = a);
+      assert(&result == &p);
+      assert(p.first.ptr == data);
+      assert(p.second.ptr == data + 5);
+    }
+  }
+
+  // Make sure we allow element conversion from a pair-like
+  {
+    std::tuple<int, char const*> a = {34, "hello world"};
+    std::pair<long, std::string> p;
+    std::same_as<std::pair<long, std::string>&> decltype(auto) result = (p = a);
+    assert(&result == &p);
+    assert(p.first == 34);
+    assert(p.second == std::string("hello world"));
+    static_assert(!std::is_assignable_v<std::pair<long, std::string>&, std::tuple<char*, std::string>>); // first not convertible
+    static_assert(!std::is_assignable_v<std::pair<long, std::string>&, std::tuple<long, void*>>); // second not convertible
+    static_assert( std::is_assignable_v<std::pair<long, std::string>&, std::tuple<long, std::string>>); // works (test the test)
+  }
+
+  // Make sure we forward the pair-like elements
+  {
+    struct NoCopy {
+      NoCopy() = default;
+      NoCopy(NoCopy const&) = delete;
+      NoCopy(NoCopy&&) = default;
+      NoCopy& operator=(NoCopy const&) = delete;
+      NoCopy& operator=(NoCopy&&) = default;
+    };
+    std::tuple<NoCopy, NoCopy> a;
+    std::pair<NoCopy, NoCopy> p;
+    p = std::move(a);
+  }
+
+  return true;
+}
+
+int main(int, char**) {
+  test();
+  static_assert(test());
+
+  return 0;
+}

libcxx/test/std/utilities/utility/pairs/pairs.pair/assign.pair_like_rv_const.pass.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17, c++20
+
+// GCC 12 chokes on using a mutable variable inside a constexpr context
+// XFAIL: gcc-12
+
+// <utility>
+
+// template <class T1, class T2> struct pair
+
+//  template <pair-like P> constexpr const pair& operator=(P&&) const;  // since C++23
+
+#include <array>
+#include <cassert>
+#include <concepts>
+#include <ranges>
+#include <string>
+#include <tuple>
+#include <type_traits>
+#include <utility>
+
+constexpr bool test() {
+  // Make sure assignment works from array and tuple
+  {
+    // Check from std::array
+    {
+      int x = 91, y = 92;
+      std::array<int, 2> a = {1, 2};
+      std::pair<int&, int&> const p = {x, y};
+      std::same_as<std::pair<int&, int&> const&> decltype(auto) result = (p = a);
+      assert(&result == &p);
+      assert(x == 1);
+      assert(y == 2);
+      static_assert(!std::is_assignable_v<std::pair<int&, int&> const&, std::array<int, 1>>); // too small
+      static_assert( std::is_assignable_v<std::pair<int&, int&> const&, std::array<int, 2>>); // works (test the test)
+      static_assert(!std::is_assignable_v<std::pair<int&, int&> const&, std::array<int, 3>>); // too large
+    }
+
+    // Check from std::tuple
+    {
+      int x = 91, y = 92;
+      std::tuple<int, int> a = {1, 2};
+      std::pair<int&, int&> const p = {x, y};
+      std::same_as<std::pair<int&, int&> const&> decltype(auto) result = (p = a);
+      assert(&result == &p);
+      assert(x == 1);
+      assert(y == 2);
+      static_assert(!std::is_assignable_v<std::pair<int&, int&> const&, std::tuple<int>>); // too small
+      static_assert( std::is_assignable_v<std::pair<int&, int&> const&, std::tuple<int, int>>); // works (test the test)
+      static_assert(!std::is_assignable_v<std::pair<int&, int&> const&, std::tuple<int, int, int>>); // too large
+    }
+
+    // Make sure it works for ranges::subrange. This actually deserves an explanation: even though
+    // the assignment operator explicitly excludes ranges::subrange specializations, such assignments
+    // end up working because of ranges::subrange's implicit conversion to pair-like types.
+    // This test ensures that the interoperability works as intended.
+    {
+      struct ConstAssignable {
+        mutable int* ptr = nullptr;
+        ConstAssignable() = default;
+        constexpr ConstAssignable(int* p) : ptr(p) { } // enable `subrange::operator pair-like`
+        constexpr ConstAssignable const& operator=(ConstAssignable const& other) const { ptr = other.ptr; return *this; }
+
+        constexpr ConstAssignable(ConstAssignable const&) = default; // defeat -Wdeprecated-copy
+        constexpr ConstAssignable& operator=(ConstAssignable const&) = default; // defeat -Wdeprecated-copy
+      };
+      int data[] = {1, 2, 3, 4, 5};
+      std::ranges::subrange<int*> a(data);
+      std::pair<ConstAssignable, ConstAssignable> const p;
+      std::same_as<std::pair<ConstAssignable, ConstAssignable> const&> decltype(auto) result = (p = a);
+      assert(&result == &p);
+      assert(p.first.ptr == data);
+      assert(p.second.ptr == data + 5);
+    }
+  }
+
+  // Make sure we allow element conversion from a pair-like
+  {
+    struct ConstAssignable {
+      mutable int val = 0;
+      ConstAssignable() = default;
+      constexpr ConstAssignable const& operator=(int v) const { val = v; return *this; }
+    };
+    std::tuple<int, int> a = {1, 2};
+    std::pair<ConstAssignable, ConstAssignable> const p;
+    std::same_as<std::pair<ConstAssignable, ConstAssignable> const&> decltype(auto) result = (p = a);
+    assert(&result == &p);
+    assert(p.first.val == 1);
+    assert(p.second.val == 2);
+    static_assert(!std::is_assignable_v<std::pair<ConstAssignable, ConstAssignable> const&, std::tuple<void*, int>>); // first not convertible
+    static_assert(!std::is_assignable_v<std::pair<ConstAssignable, ConstAssignable> const&, std::tuple<int, void*>>); // second not convertible
+    static_assert( std::is_assignable_v<std::pair<ConstAssignable, ConstAssignable> const&, std::tuple<int, int>>); // works (test the test)
+  }
+
+  // Make sure we forward the pair-like elements
+  {
+    struct NoCopy {
+      NoCopy() = default;
+      NoCopy(NoCopy const&) = delete;
+      NoCopy(NoCopy&&) = default;
+      NoCopy& operator=(NoCopy const&) = delete;
+      constexpr NoCopy const& operator=(NoCopy&&) const { return *this; }
+    };
+    std::tuple<NoCopy, NoCopy> a;
+    std::pair<NoCopy, NoCopy> const p;
+    p = std::move(a);
+  }
+
+  return true;
+}
+
+int main(int, char**) {
+  test();
+  static_assert(test());
+
+  return 0;
+}

libcxx/test/std/utilities/utility/pairs/pairs.pair/ctor.pair_like.pass.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17, c++20
+
+// <utility>
+
+// template <class T1, class T2> struct pair
+
+// template <pair-like P>
+// constexpr explicit(see-below) pair(P&&); // since C++23
+
+#include <array>
+#include <cassert>
+#include <ranges>
+#include <string>
+#include <tuple>
+#include <type_traits>
+#include <utility>
+
+constexpr bool test() {
+  // Make sure construction works from array, tuple, and ranges::subrange
+  {
+    // Check from std::array
+    {
+      std::array<int, 2> a = {1, 2};
+      std::pair<int, int> p(a);
+      assert(p.first == 1);
+      assert(p.second == 2);
+      static_assert(!std::is_constructible_v<std::pair<int, int>, std::array<int, 1>>); // too small
+      static_assert( std::is_constructible_v<std::pair<int, int>, std::array<int, 2>>); // works (test the test)
+      static_assert(!std::is_constructible_v<std::pair<int, int>, std::array<int, 3>>); // too large
+    }
+
+    // Check from std::tuple
+    {
+      std::tuple<int, int> a = {1, 2};
+      std::pair<int, int> p(a);
+      assert(p.first == 1);
+      assert(p.second == 2);
+      static_assert(!std::is_constructible_v<std::pair<int, int>, std::tuple<int>>); // too small
+      static_assert( std::is_constructible_v<std::pair<int, int>, std::tuple<int, int>>); // works (test the test)
+      static_assert(!std::is_constructible_v<std::pair<int, int>, std::tuple<int, int, int>>); // too large
+    }
+
+    // Check from ranges::subrange
+    {
+      int data[] = {1, 2, 3, 4, 5};
+      std::ranges::subrange a(data);
+      {
+        std::pair<int*, int*> p(a);
+        assert(p.first == data + 0);
+        assert(p.second == data + 5);
+      }
+      {
+        std::pair<int*, int*> p{a};
+        assert(p.first == data + 0);
+        assert(p.second == data + 5);
+      }
+      {
+        std::pair<int*, int*> p = a;
+        assert(p.first == data + 0);
+        assert(p.second == data + 5);
+      }
+    }
+  }
+
+  // Make sure we allow element conversion from a pair-like
+  {
+    std::tuple<int, char const*> a = {34, "hello world"};
+    std::pair<long, std::string> p(a);
+    assert(p.first == 34);
+    assert(p.second == std::string("hello world"));
+    static_assert(!std::is_constructible_v<std::pair<long, std::string>, std::tuple<char*, std::string>>); // first not convertible
+    static_assert(!std::is_constructible_v<std::pair<long, std::string>, std::tuple<long, void*>>); // second not convertible
+    static_assert( std::is_constructible_v<std::pair<long, std::string>, std::tuple<long, std::string>>); // works (test the test)
+  }
+
+  // Make sure we forward the pair-like elements
+  {
+    struct NoCopy {
+      NoCopy() = default;
+      NoCopy(NoCopy const&) = delete;
+      NoCopy(NoCopy&&) = default;
+    };
+    std::tuple<NoCopy, NoCopy> a;
+    std::pair<NoCopy, NoCopy> p(std::move(a));
+    (void)p;
+  }
+
+  // Make sure the constructor is implicit iff both elements can be converted
+  {
+    struct To { };
+    struct FromImplicit {
+      constexpr operator To() const { return To{}; }
+    };
+    struct FromExplicit {
+      constexpr explicit operator To() const { return To{}; }
+    };
+    // If both are convertible, the constructor is not explicit
+    {
+      std::tuple<FromImplicit, float> a = {FromImplicit{}, 2.3f};
+      std::pair<To, double> p = a;
+      (void)p;
+      static_assert(std::is_convertible_v<std::tuple<FromImplicit, float>, std::pair<To, double>>);
+    }
+    // Otherwise, the constructor is explicit
+    {
+      static_assert( std::is_constructible_v<std::pair<To, int>, std::tuple<FromExplicit, int>>);
+      static_assert(!std::is_convertible_v<std::tuple<FromExplicit, int>, std::pair<To, int>>);
+
+      static_assert( std::is_constructible_v<std::pair<int, To>, std::tuple<int, FromExplicit>>);
+      static_assert(!std::is_convertible_v<std::tuple<int, FromExplicit>, std::pair<int, To>>);
+
+      static_assert( std::is_constructible_v<std::pair<To, To>, std::tuple<FromExplicit, FromExplicit>>);
+      static_assert(!std::is_convertible_v<std::tuple<FromExplicit, FromExplicit>, std::pair<To, To>>);
+    }
+  }
+  return true;
+}
+
+int main(int, char**) {
+  test();
+  static_assert(test());
+
+  return 0;
+}