fgross added a comment.
> If you've written your own copy functions then you probably want to write
> your own move functions to allow moving, so `AllowMissingMoveFunctions`
> doesn't make sense.
The scenario I had in mind was legacy code which was written back when it still
was the "rule of three" instead of the "rule of five". Those classes with
defined destructor and copy operations are still perfectly safe, because moving
them falls back to copying. They may not be perfectly tuned for performance,
but having no move operations is not an indication for some resoure management
error. That's why I do think this options makes sense.
> I'd like an `AllowDeletedCopyFunctions` option that allows move and
> destructor functions to be missing when copying is disabled.
>
> struct A {
> A(const A&) = delete;
> A& operator=(const A&) = delete;
> }
>
My 2 cents on this one: Even with `AllowMissingMoveFunctions=1` at least the
missing destructor definition should be diagnosed, because it violates the
classic rule of three. If you delete your copy operations, you likely have some
resources that need to be taken care of in your destructor, so this piece of
code would worry me. Better be clear about it and explicitly default the
destructor.
https://reviews.llvm.org/D30610
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
