Date: Sat, 1 Oct 2022 21:28:39 -0400
On Sat, Oct 1, 2022 at 8:51 PM blacktea hamburger via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I'm using "forbid" wrong. It should be "undefined behavior," because obviously it can't be checked at compile time. It's better to make it well-formed, because unintended but correct behavior is better than undefined behavior.
That changes nothing about my question: why not? Equally importantly,
how is it "correct behavior"? It's code that is *incoherent.* You
initialized the object in a way that says something about the
relationship between the object and its storage, and you destroyed the
object in a way that says something *different* about the relationship
between the object and its storage.
Why is this "correct behavior"? Who is to say what "correct behavior"
even is if you're not consistent on what you're doing?
Not to mention the fact that, as Thiago pointed out, it is not even
"correct behavior" if `T` has an `operator delete` overload. And
again, IOC can work just fine on such types.
<std-proposals_at_[hidden]> wrote:
>
> I'm using "forbid" wrong. It should be "undefined behavior," because obviously it can't be checked at compile time. It's better to make it well-formed, because unintended but correct behavior is better than undefined behavior.
That changes nothing about my question: why not? Equally importantly,
how is it "correct behavior"? It's code that is *incoherent.* You
initialized the object in a way that says something about the
relationship between the object and its storage, and you destroyed the
object in a way that says something *different* about the relationship
between the object and its storage.
Why is this "correct behavior"? Who is to say what "correct behavior"
even is if you're not consistent on what you're doing?
Not to mention the fact that, as Thiago pointed out, it is not even
"correct behavior" if `T` has an `operator delete` overload. And
again, IOC can work just fine on such types.
Received on 2022-10-02 01:29:55