There wasn't any real/compelling reason, except for my not being sure how
much sense it makes to take container-of-member-subobject on rvalue
references.

I think your definition could be simplified as

template<typename U, typename T>
auto containing_object_of_member(U T::* pmd, std::same_as<U> auto && m) ->
__merge_cvref_t<decltype(m), T>;

(again, modulo constexpr + noexcept).

However, I guess I'm not sure about:

* Does this operation make sense for rvalue references?
* How to constrain the auto return value to return the same "kind" of
reference as m (since this must not return by value, it needs to return a
reference)
* Does the standard actually accept this kind of code? I had gone with the
overloads in proposal since I didn't think the standard accepted this kind
of complicated addition.

Any clarity on those points from std-proposals would be appreciated.


On Sat, Nov 13, 2021 at 5:11 AM Gašper Ažman <gasper.azman_at_[hidden]> wrote:

> 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
>>
>