Yes. C++ already has no way to detect dangling pointers or references to
objects whose lifetime has ended, so my suggestion doesn't make anything
worse. But it "trusts the programmer" to arrange memory such that the
access is correct, without the compiler stepping in to silently subvert the
program because it believes the behavior is undefined. It also trusts the
programmer when type punning occurs.

In my model, constructors and destructors are still functions that make
changes to the memory of the object, and are still called at the same times
they are now. But the programmer is permitted to arrange memory in other
ways, and if an operation of a type applied to that memory finds it
suitably arranged, the operation succeeds.

On Tue, Apr 27, 2021, 2:40 PM Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Tue, 27 Apr 2021 at 21:22, Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Tue, 27 Apr 2021 at 21:12, Hyman Rosen <hyrosen_at_[hidden]> wrote:
> > >
> > > I respectfully believe you are giving me the courtier's reply:
> https://en.wikipedia.org/wiki/Courtier%27s_reply
> > >
> > > That is, one does not need to be a tailor to proclaim that the emperor
> is naked. Things like bit_cast and launder, the inscrutability of the
> aliasing rules, the questions about the pointer arithmetic used to
> implement vector, all show that something is very wrong with the object
> model.
> > >
> > > There's is also zero chance that a proposal to model objects as
> memory+type would ever be accepted, because it would do away with many of
> the permissions the current situation gives to compiler writers to optimize
> code (which is also permission to disregard programmer intent).
> >
> > So, you're playing a broken record, complaining when it's described a
> > broken record, and plan to continue to do nothing
> > about it but keep playing it?
>
> More concretely:
> You wrote "The wrong definition used by C++ requires that objects be
> "created", and have "lifetimes" that "begin" and "end"..."
>
> So you're suggesting that an object of type std::string should just
> spring into existence the moment you try to refer to
> any random memory location with a std::string glvalue?
>
> These rules are not just for optimization, no matter how many times
> you incorrectly claim they are. They're all about
> correctness, and optimizers can use them because they allow optimizers
> to verify that certain optimizations are correct
> to perform. With the "rule" you suggest, I can't know whether a string
> object is valid, and tools can't tell me, because
> all objects everywhere are always valid, even though they obviously aren't.
>
> Tell me again why anyone should listen to these suggestions of yours?
>