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@lists.isocpp.org> 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@gmail.com> wrote:
Hello,


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@lists.isocpp.org> wrote:

> On Nov 9, 2021, at 2:24 AM, Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>
> On Tue, Nov 9, 2021 at 1:31 AM language.lawyer--- via Std-Proposals
> <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals