I don't think std::pair allows the members to be potentially overlapping, which means that programs that memcpy over first and second are valid now. So this would be a breaking change for pair.

I think tuple allows this.



On 25 August 2023 17:52:06 BST, connor horman via Std-Proposals <std-proposals_at_[hidden]> wrote:
>Could it be implementation-defined/unspecified whether the fields of
>`std::pair` and `std::tuple` are `[[no_unique_address]`?
>That would allow existing implementations to keep the definitions as-is,
>and new implementations (or ones that are willing to break abi) can add the
>attribute in. I'm not sure that is allowed as-is in the standard.
>
>On Fri, 25 Aug 2023 at 12:30, Barry Revzin via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>>
>>
>> On Fri, Aug 25, 2023, 10:08 AM Hewill Kang via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Hi all experts,
>>>
>>> boost::compressed_pair is widely used as a replacement for std::pair in
>>> order to save storage when one of the data members is an empty class.
>>>
>>> The __compressed_pair helper class, which is similar to
>>> boost::compressed_pair, is also widely used in libc++.
>>>
>>> I wonder if we could get this compression optimization at almost no cost
>>> if add the C++ [[no_unique_address]] attribute to the members of
>>> std::pair:
>>>
>>> namespace std {
>>> template<class T1, class T2>
>>> struct pair {
>>> using first_type = T1;
>>> using second_type = T2;
>>>
>>> [[no_unique_address]] T1 first; // <- here
>>> [[no_unique_address]] T2 second; // <- here
>>> };
>>> }
>>>
>>> This looks reasonable to me, and almost achieves the equivalent of
>>> boost::compressed_pair.
>>>
>>> What do you guys think about this? This seems like a great enhancement to
>>> me. Or does this kind of practice bring certain issues?
>>>
>>> Comments are very welcome.
>>>
>>> Hewill
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>>
>> std::pair and std: tuple aren't even trivially copyable when they could be
>> due to ABI. This would be even worse.
>>
>> Sorry,
>>
>> Barry
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>