On Wed, 29 Nov 2023 at 12:41, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 11/29/23 15:18, Jonathan Wakely via Std-Proposals wrote:
> >
> >
> > On Wed, 29 Nov 2023 at 11:13, Giuseppe D'Angelo via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> > wrote:
> >
> > Il 29/11/23 11:46, Breno Guimarães via Std-Proposals ha scritto:
> > > I don't think that's UB. Not calling the destructor is not UB.
> >
> > I was referring to the memset. But indeed I can't seem to find a
> > provision that you can't just overwrite bytes of an arbitrary object
> > using it. Interesting pub quiz question...
> >
> >
> > There's no guarantee that the bytes of std::future<bool> are contiguous,
> > so memset could overwrite something that's not part of the object.
> >
> > And clearly zeroing out the bytes of a std::vector and then expecting it
> > to keep working afterwards isn't reasonable. I think fiddling with the
> > underlying bytes is only valid for trivially copyable types.
>
> Not even then, I think. It is permitted for std::optional<T> to store
> the "populated" flag in the tail padding of the stored object (e.g. by
> creating an object of a class that derives from T), which means that the
> memset would corrupt that flag.
>

I don't think compilers will reuse tail padding of trivially-copyable
types, precisely because using memcpy to change the value of a trivially
copyable type is allowed.

In any case, using memset can produce an invalid object even on
trivially-copyable types. The object representation created by memset might
not be a valid value representation for the type. Only memcpy of bytes from
a valid value representation of another object is guaranteed to work.

But this is all a diversion from the fact that this abandon proposal is
just a bad idea.