Modifies the description of self-assignment in the move assignment operator

[Mq-b]

I think the description and handling of securing self-assignment is too simplistic.

Not all cases should use self-assignment checking to ensure self-assignment security, and in many cases it is not necessary.

MSVC STL std::unique_ptr、std::shared_ptr：

template <class _Dx2 = _Dx, enable_if_t<is_move_assignable_v<_Dx2>, int> = 0>
_CONSTEXPR23 unique_ptr& operator=(unique_ptr&& _Right) noexcept {
    reset(_Right.release());
    _Mypair._Get_first() = _STD forward<_Dx>(_Right._Mypair._Get_first());
    return *this;
}

shared_ptr& operator=(shared_ptr&& _Right) noexcept { // take resource from _Right
    shared_ptr(_STD move(_Right)).swap(*this);
    return *this;
}

---

class Foo {
    std::string s;
    int i;
};

Foo is inherently self-assignment safe and does not require any additional processing.

• In short: I don't think we should just describe a simple self-assignment detection method.

[prmerger-automator]

@Mq-b : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit eb8b75e:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/cpp/move-constructors-and-move-assignment-operators-cpp.md	✅Succeeded

For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[Jak-MS]

@TylerMSFT

• Can you review this PR?
• IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[prmerger-automator]

@Mq-b : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[TylerMSFT]

We wouldn't say that there are other ways unless we were going to describe them all. Instead, : "Another way is copy-and-swap" without the code ticks. But we've also just complicated the situation by providing an alternative without explaining why it might be desirable. I assume you like it because it does the check to make sure the objects aren't the same for you? If so, let's call that out.

[Mq-b]

CppCoreGuidelines.

In short, I hope that the description is not so "absolute", we should analyze the specific problem.

We don't have to list too many other ways to write it, but in the words Try to say a little that "there are other ways" is still needed.

[TylerMSFT]

I prefer the original wording. 'judgement' and 'safe' are uncommon and ambiguous in technical writing. And 'judgement' wouldn't translate well, either. Can you restore the original?

[Mq-b]

I prefer the original wording. 'judgement' and 'safe' are uncommon and ambiguous in technical writing. And 'judgement' wouldn't translate well, either. Can you restore the original?

The original description was too absolute.

What I mean here is to ensure "self-assignment-safe", but the original text does not mention this key term.

[frederick-vs-ja]

I'd like to say "[...], no operation should be performed if one tries to assign the object to itself. The easiest way is adding a conditional statement that skips operations when both operands refer to the same object."

[TylerMSFT]

Left a couple comments.

[frederick-vs-ja]

It's a bit weird to mention shared_ptr here. And shared_ptr(_Right).swap(*this) is performed in copy assignment, not in move assigment.

In this move-constructors-and-move-assignment-operators-cpp.md, I think we should say MemoryBlock(std::move(other)).swap(*this). BUT we also need to add a swap function together.

[frederick-vs-ja]

It's curious (or rather old-fashioned) that the whole file mentions neither swap nor exchange. Perhaps it need to be substantially updated.

[Mq-b]

It's curious (or rather old-fashioned) that the whole file mentions neither swap nor exchange. Perhaps it need to be substantially updated.

Yes!