Re: C++17 std::launder and aliasing

[Ville Voutilainen <ville dot voutilainen at gmail dot com>]

On 24 October 2016 at 11:21, Richard Biener <rguenther@suse.de> wrote:
>> And I'm afraid just conservatively assuming any method call could change
>> the object on which it has been called on into something different would
>> pretty much kill most of the devirtualization.
>> CCing Honza.
>
> But we already assume any function call may - so if the C++ standard
> allows this we have to assume any method call may do so as well.

I thought we assume the opposite, and launder allows us to turn off
that assumption.

> See my destructor example on how the C++ FE also mishandles this case.

For that case, I don't know how to launder.

> IMHO this is worth a DR and a clarification on whether this is allowed.

Reusing the storage of an object is allowed. When such reusing is done
and an object of
a different type is created in the storage, the destructor of the
original object can't be implicitly
called. This is [basic.life]/5:
"A program may end the lifetime of any object by reusing the storage
which the object occupies or by explicitly
calling the destructor for an object of a class type with a
non-trivial destructor. For an object of a class type
with a non-trivial destructor, the program is not required to call the
destructor explicitly before the storage
which the object occupies is reused or released; however, if there is
no explicit call to the destructor or if a
delete-expression (5.3.5) is not used to release the storage, the
destructor shall not be implicitly called and
any program that depends on the side effects produced by the
destructor has undefined behavior."

In other words, there's no way to launder the destructor example you
provided, but the destruction
of a is UB. The wording says "shall not be called", but since that is
not diagnosable, the wording could
be clarified that such a call has undefined behavior.