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