Is there a reason for not taking the member subject as a
concept-constrained forwarding reference? That way you avoid having an
overload set, which is far more useful.

Specifically, the concept being

template <class T, class U>
concept __similar = std::is_same<std::remove_cvref_t<T>, U>;

template <typename U, typename T>
auto containing_object_of(U T::* p, __similar<U> auto&& m) ->
__merge_cvref_t<decltype(m), T>;

Where __merge_cvref_t is defined as in the forward_like paper addendum.

Plus constexpr, obviously.


On Fri, Nov 12, 2021, 23:44 Michael Scire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> ...somehow I managed to forget to add constexpr/noexcept specifiers. The
> PDF is updated, my apologies about that.
>
> On Fri, Nov 12, 2021 at 1:17 PM Michael Scire <sciresm_at_[hidden]> wrote:
>
>> Hello,
>>
>> I wrote a first draft of a proposal for this:
>> https://github.com/SciresM/containing_object_of_member/blob/master/containing_object_of_member.pdf
>>
>> I would appreciate feedback; it will probably need substantial revision,
>> as I haven't written a proposal before.
>>
>> Thanks!
>>
>>
>> On Tue, Nov 9, 2021 at 2:41 AM Tom Honermann via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>>
>>> > On Nov 9, 2021, at 2:24 AM, Jason McKesson via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>> >
>>> > On Tue, Nov 9, 2021 at 1:31 AM language.lawyer--- via Std-Proposals
>>> > <std-proposals_at_[hidden]> wrote:
>>> >>
>>> >>> On 09/11/2021 09:22, Tom Honermann via Std-Proposals wrote:
>>> >>> Note that an array element is a member subobject of the array of
>>> which it is an element.
>>> >>
>>> >> No, it is not.
>>> >
>>> > Just to make this clear, array elements are not *member* subobjects of
>>> > the array. They are subobjects of the array, just not members.
>>>
>>> Yes, thank you for the correction. My intended point was that the
>>> suggested names using the “containing” terminology could be read as being
>>> applicable to array elements as well. Since that is not intended, a name
>>> that more explicitly limits applicability may be desired. E.g.,
>>> std::containing_object_of_member(). That would exclude operations on base
>>> class subobjects, but perhaps there is little motivation to support them
>>> given that the type of the containing object could not be deduced (but
>>> could be explicitly provided).
>>>
>>> Tom.
>>>
>>> > --
>>> > Std-Proposals mailing list
>>> > Std-Proposals_at_[hidden]
>>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>