On Fri, 23 Dec 2022 at 02:24, Thiago Macieira <thiago_at_[hidden]> wrote:

> On Thursday, 22 December 2022 08:17:40 -03 Sebastian Wittmeier via Std-
> Proposals wrote:
> > If the destructor is called on the reference, the original object would
> be
> > destroyed.
>
> How does it prevent the original object, which may not be in the current
> scope, from doing a double-destroy?
>
> void f(MyType &b)
> {
> reloc b;
> }
>

Exactly, which is why this only ends the lifetime of the reference, not the
referent.

You can say that it's the caller's responsibility, which I find there may
> be
> good reasons for. For example, b could be stored in an optional-like
> holder
> that can be told to drop the contents on the floor as having already been
> destroyed.
>
> But that's hardly RAII. If MyType is relocatable, then one could have
> simply
> extracted it off from the optional-like holder via return-by-value instead
> of
> pointing to the object inside the optional-like.
>

Yes, if you want to pass responsibility for the MyType object to the called
function you would pass by value. If you want to make it contingent whether
f takes ownership, you would pass `optional<MyType>&`.

But then this means that you can't do some operations on a non-const lvalue
> reference that you can on real objects. That's weird language break.
>

A reference does not give you control over the original object's lifetime.
That might be a point of distinction between references and their
referents, but it hardly seems weird.