[libcxx-commits] [PATCH] D121213: [libc++] Enable modernize-use-equals-delete

Nikolas Klauser via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Nov 10 14:48:55 PST 2022


philnik marked an inline comment as done.
philnik added a comment.

In D121213#3392906 <https://reviews.llvm.org/D121213#3392906>, @ldionne wrote:

> The important bit is this (emphasis mine):
>
>> A type is considered non-trivial for the purposes of calls if:
>>
>> - it has a non-trivial copy constructor, move constructor, or destructor, or
>> - **all** of its copy and move constructors are deleted.
>
> I went through all the changes in this patch, and I think the key question we need an answer to is:
>
> When a copy assignment operator or copy constructor is explicitly deleted, there is no implicit move constructor generated by the compiler. But does the compiler not declare any move constructor, or does it declare one and mark it as deleted? I wasn't able to find out by reading http://eel.is/c++draft/class.copy.ctor, but it may be easy to answer for others here.
> This is relevant because some classes go from having a user-declared private `operator=(T const&)` to having a deleted one. I believe it's possible for such a type to be trivial for the purpose of calls. However, if we change it to `operator(T const&) = delete` **and** the compiler then implicitly declares `T(T const&) = delete`, we'd go from trivial to non-trivial.

I think the compiler doesn't declare one. The explicitly deleted copy constructor counts as a user-declated constructor, which means that no move constructor will be declared. Deleting a copy assignment operator also doesn't delete the copy constructor (https://godbolt.org/z/hc18qhfv1), so that part shouldn't matter.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121213/new/

https://reviews.llvm.org/D121213



More information about the libcxx-commits mailing list