Would it be wise for me to start a new thread for the draft proposal from a
few messages back?

Not sure whether the lack of commentary is indicative of low visibility
(due to the thread being deep), people being busy, or people not having
much to say on the topic.

On Sat, Nov 13, 2021 at 12:00 PM Michael Scire <sciresm_at_[hidden]> wrote:

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