On Wed, Sep 2, 2020 at 6:31 PM Steve Hearnden via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> My proposal was intended to allow Arthur’s sample to be written as below.

I would say that the primary benefit of what you want is that it feels
more natural to a C++ programmer than having to manually `alignas` an
array of bytes, computing the correct byte size, and so forth. That
is, the benefit is legibility and ease of understanding, particularly
for new users.

Here's the thing though: this stuff *is very dangerous*. That
statement does not create an object (and it so clearly doesn't create
an object that I would object to using an attribute for it); it just
creates the storage for an eventual object. But it *looks* like it
creates an object.

By contrast, an aligned array of bytes looks exactly like what it is:
aligned storage. It's clear to all involved (who know the idioms, at
least) that you're writing code that deals specifically with
unformatted memory. That's good; the code is communicating effectively
with the reader.

A variable definition that looks like it creates an object but doesn't
is not effectively communicating. Even if you put a keyword in front
of it, it superficially looks like it's creating an object.

The primary benefit of what you're doing is that it makes it easier
for newer, less-experienced C++ programmers to do more low-level tasks
without having a lot of experience at them. The primary downside is
that it makes it easier for newer, less-experienced C++ programmers to
do more low-level tasks without having a lot of experience at them.

Directly creating objects like this is something that needs to be
possible, but it shouldn't be trivially easy either.