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.

On Sun, Oct 2, 2022 at 12:24 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, Oct 1, 2022 at 10:10 AM blacktea hamburger via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >>
> >> For example:
> >>
> >> ```
> >> auto *p = operator new(1);
> >> auto *pc = new(p) char;
> >> delete pc;
> >> ```
> >>
> >> That delete is invalid, and it *should be*. If you use two-step object
> >> creation (allocate memory, then put an object into it), you should use
> >> two-step object destruction (destroy the object, then deallocate the
> >> memory).
> >
> >
> > In fact, it is legal. The standard does not specify that a
> new-expression cannot be a placement-new.
>
> Then I would say that this is a defect in the standard. `operator
> new`+placement-`new T` is *not* identical to `new T` for all types
> `T`. As Thiago mentioned, if `T` overloads `operator new/delete`, then
> this will cause a problem when you try to use the `delete` expression
> instead of doing the proper inverse operation (ie: explicit destructor
> call followed by `operator delete`).
>
> It doesn't make sense to use two-stage object creation but one-stage
> object destruction. Especially when there are cases where it
> explicitly will not work. Better to forbid them all the time than to
> encourage people to roll the dice.
>
> > The standard should not forbid some code that is not very good, but
> correct.
>
> Um... why not?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>