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 <hash_map>, these occurrences are:
|
template <class _Valty, class = enable_if_t<is_constructible_v<value_type, _Valty>>>
|
|
template <class _Valty, class = enable_if_t<is_constructible_v<value_type, _Valty>>>
|
|
template <class _Valty, class = enable_if_t<is_constructible_v<value_type, _Valty>>>
|
|
template <class _Valty, class = enable_if_t<is_constructible_v<value_type, _Valty>>>
|
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.)
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
<hash_map>, these occurrences are:STL/stl/inc/hash_map
Line 193 in 28ec9a3
STL/stl/inc/hash_map
Line 198 in 28ec9a3
STL/stl/inc/hash_map
Line 376 in 28ec9a3
STL/stl/inc/hash_map
Line 381 in 28ec9a3
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.)