On Sep 9, 2021, at 12:02 AM, Michael Schellenberger Costa via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

Am Do., 9. Sept. 2021 um 06:59 Uhr schrieb Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org>:
On Wed, Sep 8, 2021 at 2:29 PM D'Alessandro, Luke K via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> I guess I have two questions:
> 1. Does std::construct_at change the active member of a union?

As stated in [class.union]/2, "a non-static data member is active if
its name refers to an object whose lifetime has begun and has not
ended." `construct_at` can begin the lifetime of objects (which can
also cause the lifetime of other overlapping objects to end).

Therefore, it can change the active union member.

While `std::construct_at` does indeed begin the lifetime of the element it constructs, the lifetime of the array has not begun. Therefore, forming a reference to an object outside of its lifetime is UB, so `&u.data[1]` is not possible. We had the exact same issue recently when implementing constexpr std::string for MSVC STL. There we have an indirection to `char_traits` and would need to call `char_traits::assign(&sso_storage[0], CharType())` which again is invalid due to forming of the reference to `sso_storage[0]` outside of its lifetime

If you have a non-assignable class then the best way around is an 
if constexpr(std::is_assignable_v) {
     // change the active member of the union to the array here.

Thanks Michael,

My only confusion is the statement that `&u.data[1]` is a problem is that https://eel.is/c++draft/class.union#general-example-2 seems to do exactly that.

Just so I understand in the future, is the example okay because it doesn’t apply `&` or is it okay because it’s part of the statement that is actually starting the lifetime?



Std-Proposals mailing list