if (this != &rhs) in unique ptr

[DenisYaroshevskiy]

Hi

This this != _STD addressof(_Right) seems redundant

STL/stl/inc/memory

Line 3264 in 994f941

if (this != _STD addressof(_Right)) {

I can't say I understand what are you trying to enable if away, tbh though - but this seems like a less specialized version of the previous assignment.

Here is libc++ - no check
https://github.com/llvm/llvm-project/blob/93a2feccbc909230b6a091f5836b92739bd12941/libcxx/include/__memory/unique_ptr.h#L231

Can you maybe delete it?

[CaseyCarter]

This self-assignment guard is both unnecessary and observably non-conforming. We should absolutely get rid of it.

[MikeGitb]

Why is it non-conforming?

[CaseyCarter]

Why is it non-conforming?

The deleter and/or pointer types could be user-provided, and could therefore observe the absence of the "release-and-reset" or "deleter self-assignment" effects that the Standard mandates we must implement. In fairness, nobody has ever complained about this so it's very likely nobody cares. The real issue is the cost of the unnecessary branch.

[Osyotr]

Casey Carter (@CaseyCarter) I think the question was about enable_if one line above the linked line. (Haha off-by-one error)

[CaseyCarter]

Casey Carter (@CaseyCarter) I think the question was about enable_if one line above the linked line. (Haha off-by-one error)

My impression is that the question is stating "this conditional seems pointless, but I can't be certain since I don't know what the enable_if is doing". I addressed the conditional, but didn't point out that the enable_if is there to make this assignment operator "disappear" when the unique_ptr's deleter type isn't move assignable, i.e., it's implementing this constraint.

[DenisYaroshevskiy]

The enable_if question is about having two copies of move assignment, one with check, one without

STL/stl/inc/memory

Line 3256 in 994f941

_CONSTEXPR23 unique_ptr& operator=(unique_ptr<_Ty2, _Dx2>&& _Right) noexcept {

[CaseyCarter]

This function handles move assignments:

STL/stl/inc/memory

Lines 3262 to 3269 in 994f941

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

and this one handles rvalue converting assignments:

STL/stl/inc/memory

Lines 3252 to 3260 in 994f941

	template <class _Ty2, class _Dx2,
	enable_if_t<conjunction_v<negation<is_array<_Ty2>>, is_assignable<_Dx&, _Dx2>,
	is_convertible<typename unique_ptr<_Ty2, _Dx2>::pointer, pointer>>,
	int> = 0>
	_CONSTEXPR23 unique_ptr& operator=(unique_ptr<_Ty2, _Dx2>&& _Right) noexcept {
	reset(_Right.release());
	_Mypair._Get_first() = _STD forward<_Dx2>(_Right._Mypair._Get_first());
	return *this;
	}

They're both specified by https://eel.is/c++draft/unique.ptr.single.asgn. Comparing the specifications, we see the latter overload has a few extra constraints resulting in a more complicated enable_if with a conjunction of terms. Oddly enough the bodies of both overloads could be identical. In both cases, the enable_if requires that the deleter of the right-hand-side of the assignment (the argument to the assignment operator) is assignable to the deleter of the left-hand-side (*this).