>> The creation of an object of type T would end the lifetime of the array
>> elements, so accessing them would be UB.
>>
>
> An array of unsigned char or std::byte can have an object of some other
> type nested within it, so the array's lifetime is not ended.
Right, but I wrote that the lifetimes of the array *elements* would end.
There is no "nested within" relation between the elements and an object which is placed over them.
[intro.object]/3
If a complete object is created ([expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std::byte” ([cstddef.syn]), that array provides storage for the created object if: ...
[intro.object]/4
An object a is nested within another object b if: ... or b provides storage for a, or ... [basic.life]/1
The lifetime of an object o of type T ends when: ...
the storage which the object occupies is released, or is reused by an object that is not nested within o ([intro.object]).
>> This just shows that the access to object representations do not fit well
>> into the current model of the C++ abstract machine.
>>
>
> Indeed. On one hand, one could conclude that people who want to access
> object representations should just suck it up. On the other hand, one could
> observe that the current C++ memory and object model results in a lot of
> pre-C++17 code being broken, and conclude that it should be revised.
>
> Besides, even if you think that no one should ever try to access object
> representations of anything much more complicated than a struct with a
> bunch of ints in it, do you think it is reasonable to limit typical usage
> of offsetof to such types as well? If I have a pointer to a member of some
> class that is standard-layout but not implicit-lifetime, should there not
> be a way for me to get a pointer to the enclosing class using pointer
> arithmetic? Are you comfortable with letting all the existing code of this
> form, written before C++17, continue to be broken? What did we gain from
> the C++17 changes that was so beneficial that it justified *silently
> breaking* said code? What about the fact that the migration effort for such
> code can be significant (given, as I've pointed out, the inadequacies of
> the proposed std::bless solution)?
Isn't offsetof usually used in some low-level code which typically also breaks the strict aliasing rule?
There are compiler flags making the later behavior defined.
It is not forbidden for implementations to define behavior which the standard does not define.
I don't see why that is necessarily the case. It could, for example, be used to allow a user to remove an object from a node-based container given a pointer to the object. There's no reason why such code should have to depend on special flags to make strict aliasing violations well-defined. Oh, sure, you can rewrite the container so that its API is based on iterators instead, to avoid this problem---and, of course, you'll also have to rewrite ALL the code that uses it. As I said, the migration effort is "significant".