1. Ah, looks like I messed up that wording, I'll fix that. 

2. Didn't consider that: I'll specify that it attempts to bind to an object that isn't an element of an object representation first, and if one does not exist, the result is unspecified.

Sent from my Samsung Galaxy smartphone.

-------- Original message --------
From: "language.lawyer--- via Std-Proposals" <std-proposals@lists.isocpp.org>
Date: 8/19/19 15:44 (GMT-05:00)
To: std-proposals@lists.isocpp.org
Cc: language.lawyer@gmail.com
Subject: Re: [std-proposals] Allowing access to object representations

1. You propose to add into [intro.object]/1:
> The object representation of an object of object o is guaranteed to appear in the object representation of o.

Looks like you some words.

2. Consider this:

struct S { int i; } s;
auto p = std::launder(static_cast<unsigned char*>(static_cast<void*>(&s)));
// reinterpret_cast was intentionally not used!

In your proposal, the object representation of `s.i` lays ontop of the object representation of `s` and the `unsigned char` element of both of them are within their lifetime.
Pointer to which of two `unsigned char` objects the invocation of `std::launder` should produce?

On 19/08/2019 03:52, Krystian Stasiowski via Std-Proposals wrote:
> Ok, I've gone through the issues that have brought up, here's a link to the
> draft for R1 (unfortunately, I can only provide the raw text for it, on
> vacation right now so I am unable to make the pdf):
>
> In short, I changed [intro.object] p9 to specify that elements of an object
> representation can be overlap (the nested within relationship, in my
> opinion doesn't make sense, since the object representation "overlays" the
> object, and several elements of object representations can overlay each
> other), changed [expr.add] p6 to allow for pointer addition and subtraction
> for pointers of type char, unsigned char, and std::byte (unsigned char
> included since char and byte are their own object representations) pointing
> to an element of an object representation, extended the nested within
> guarantee to objects of nonzero size, and extended to definition of
> contiguous layout objects to multi-dimensional arrays (since array elements
> are contiguously allocated http://eel.is/c++draft/dcl.array#6)
>
>
> On Sun, Aug 18, 2019 at 9:41 AM sdkrystian <sdkrystian@gmail.com> wrote:
>
>> Although, it would still be contiguous; http://eel.is/c++draft/dcl.array#6
>>
>> Perhaps extending the definition to cover multidimensional arrays would be
>> worth doing.
>>
>>
>>
>> Sent from my Samsung Galaxy smartphone.
>>
>> -------- Original message --------
>> From: Language Lawyer via Std-Proposals <std-proposals@lists.isocpp.org>
>> Date: 8/18/19 08:34 (GMT-05:00)
>> To: std-proposals@lists.isocpp.org
>> Cc: Language Lawyer <language.lawyer@gmail.com>
>> Subject: Re: [std-proposals] Allowing access to object representations
>>
>> And multidimensional array of, say, `unsigned char` is its own object
>> representation?
>> If so, this does not match the expectation that the object representation
>> is contiguous.
>>
>> On 18/08/2019 03:33, sdkrystian via Std-Proposals wrote:
>>> Yes, in which case it is its own object representation
>>>
>>>
>>>
>>> Sent from my Samsung Galaxy smartphone.
>>>
>>> -------- Original message --------
>>> From: Language Lawyer via Std-Proposals <std-proposals@lists.isocpp.org>
>>> Date: 8/17/19 20:30 (GMT-05:00)
>>> To: std-proposals@lists.isocpp.org
>>> Cc: Language Lawyer <language.lawyer@gmail.com>
>>> Subject: Re: [std-proposals] Allowing access to object representations
>>>
>>> Ah, so the object representation of an object of type T is a sequence of
>> `unsigned char` objects unless T is (cv-qualified) `char` or `std::byte`
>> (or array thereof)?
>>>
>>> On 18/08/2019 03:24, sdkrystian via Std-Proposals wrote:
>>>   > Same thing applies. I'll have to change [expr.add]/6 to make it work.
>>>   >
>>>   >
>>>   >
>>>   > Sent from my Samsung Galaxy smartphone.
>>>   >
>>>   > -------- Original message --------
>>>   > From: Language Lawyer via Std-Proposals <
>> std-proposals@lists.isocpp.org>
>>>   > Date: 8/17/19 20:21 (GMT-05:00)
>>>   > To: std-proposals@lists.isocpp.org
>>>   > Cc: Language Lawyer <language.lawyer@gmail.com>
>>>   > Subject: Re: [std-proposals] Allowing access to object representations
>>>   >
>>>   > And for an object `a` of type `char`?
>>>   >
>>>   > On 18/08/2019 03:18, sdkrystian via Std-Proposals wrote:
>>>   >  > The object representation of the object is itself... For an object
>> `a` of type unsigned char, it's object representation is `a`
>>>   >  >
>>>   >  >
>>>   >  >
>>>   >  > Sent from my Samsung Galaxy smartphone.
>>>   >  >
>>>   >  > -------- Original message --------
>>>   >  > From: Language Lawyer via Std-Proposals <
>> std-proposals@lists.isocpp.org>
>>>   >  > Date: 8/17/19 16:49 (GMT-05:00)
>>>   >  > To: std-proposals@lists.isocpp.org
>>>   >  > Cc: Language Lawyer <language.lawyer@gmail.com>
>>>   >  > Subject: Re: [std-proposals] Allowing access to object
>> representations
>>>   >  >
>>>   >  >  > The object representation of an object of type unsigned char,
>> char, std::byte, or an array of such types (ignoring cv-qualification), is
>> itself.
>>>   >  >
>>>   >  > What does this cryptic "is itself" mean?
>>>   >  > --
>>>   >  > 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
>>>
>> --
>> 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