As I understand it, in this proposal relocation of an automatic variable
does not terminate its lifetime. Will references and pointers to that
object continue to be valid? This does not appear to be addressed in the
paper.

If they do not continue to be valid, how is this enforced? Apparently the
destructor is still called; how is access to the object from its destructor
different to access via preexisting pointers and references?

What advantage does this proposal provide over the use of e.g. clang-tidy
user-after-move detection?

The proposal appears to state that the destructor is still called, implying
that relocation must leave the object in a destructible empty state,
presumably usually identical to the moved-from state. This implies
branching in the destructor to check for this state, whereas if lifetime
was ended (thus no destructor call on relocated objects) this could be
avoided.

To summarize, there is insufficient benefit here over the status quo to
justify a new keyword and value category.


On Sat, 30 Apr 2022 at 19:06, William Linkmeyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Can we get a bullet-point list of all the criticisms so that they can be
> addressed?
>
> WL
>
> > On Apr 30, 2022, at 11:19 AM, Giuseppe D'Angelo <
> giuseppe.dangelo_at_[hidden]> wrote:
> >
> > On 30/04/2022 16:34, William Linkmeyer wrote:
> >> Giuseppe wrote:
> >>> (From a syntax point of view, I'm not sure how that is desirable, as
> one could no longer something like `other = reloc obj; delete &obj;`, but I
> don't think it's a particularly compelling use case...)
> >> I would argue that the example given*is* a compelling use case for
> reloc. Remembering to delete objects (esp. at the right time) is a recipe
> for disaster.
> >
> > My example was about a use case for which one does need to use the name
> of the relocated object. I was just not sure about how realistic it is.
> > The example had nothing to do with "remembering to delete", we have
> smart pointers and other strategies for that.
> >
> >
> >> Anyway, for what it’s worth, I think this is a compelling paper and
> would like to help move it forward in a constructive way.
> >
> > The above point wasn't my main criticism. My main criticism was that the
> paper seems to settle on a convoluted syntax for the already existing move
> semantics (plus the p1144 bits). Did I misunderstand something?
> >
> >
> > Thanks,
> > --
> > Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>