<memory>: Consistently use `int = 0` SFINAE

[StephanTLavavej]

Over the years, we settled on a consistent pattern for SFINAE: default template arguments of the form enable_if_t<CONDITION, int> = 0. This works in a wide variety of situations, including when we have an overload set where SFINAE makes exactly one overload viable. There are a few remaining occurrences of SFINAE that don't follow this pattern.

In <memory>, these occurrences are _Enable_ctor_reset and _Enable_conversion:

STL/stl/inc/memory

Lines 1933 to 1938 in 28ec9a3

	template <class _Uty, class _Is_nullptr = is_same<_Uty, nullptr_t>>
	using _Enable_ctor_reset = enable_if_t<is_same_v<_Uty, pointer> //
	|| _Is_nullptr::value //
	|| (is_same_v<pointer, element_type*> //
	&& is_pointer_v<_Uty> //
	&& is_convertible_v<remove_pointer_t<_Uty> (*)[], element_type (*)[]>)>;

STL/stl/inc/memory

Lines 1975 to 1978 in 28ec9a3

	template <class _Uty, class _Ex, class _More, class _UP_pointer = typename unique_ptr<_Uty, _Ex>::pointer,
	class _UP_element_type = typename unique_ptr<_Uty, _Ex>::element_type>
	using _Enable_conversion = enable_if_t<conjunction_v<is_array<_Uty>, is_same<pointer, element_type*>,
	is_same<_UP_pointer, _UP_element_type*>, is_convertible<_UP_element_type (*)[], element_type (*)[]>, _More>>;

This change is currently blocked by a compiler bug. We need to provide a reduced test case to the compiler front-end team.

(Split from #187.)

[MikeGitb]

Just curious: What is the advantage of this form over class = std::enable_if_t<Cond>?

[StephanTLavavej]

Consider the common scenario of having two overloads, one of which is enabled when is_cat_v<T> and the other when !is_cat_v<T>. If you try to do this with class = enable_if_t<Cond>, it won’t compile. That’s because the compiler sees two templates, both taking an unnamed type parameter, with different default arguments; that looks like conflicting definitions.

If instead you use enable_if_t<Cond, int> = 0, then the compiler has to perform substitution and SFINAE before discovering what the non-type template parameter is (humans can see that it’s always int or nonexistent). This means that the compiler will only ever see one overload with an int template parameter and the other will vanish.

[MikeGitb]

Thanks for the explanation.

[StephanTLavavej]

I believe that this is now unblocked; it should be possible to resolve this with the same technique that @BillyONeal used in #244.