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@gmail.com> 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@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