On 22 November 2016 at 15:36, Jonathan Wakely <jwak...@redhat.com> wrote: >> +#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or >> gnu++11 >> + template<typename _T1, typename _T2> >> + inline >> + typename enable_if<__not_<__and_<__is_swappable<_T1>, >> + __is_swappable<_T2>>>::value>::type >> + swap(pair<_T1, _T2>&, pair<_T1, _T2>&) = delete; > > > Is there any advantage to using __not_ here, rather than just: > > typename enable_if<!__and_<__is_swappable<_T1>, > __is_swappable<_T2>>::value>::type > > ? > > __not_ is useful as a sub-expression of an __and_ / __or_ expression, > but at the top level doesn't seem to buy anything, and is more typing, > and requires indenting the code further.
There's no particular advantage, it's just a habitual way to write a mixture of __and_s and __not_s that I suffer from, whichever way the nesting is. I'm also not consistent: + inline enable_if_t<!(is_move_constructible_v<_Tp> && is_swappable_v<_Tp>)> + swap(optional<_Tp>&, optional<_Tp>&) = delete; so I can certainly change all these swaps to use operator! rather than __not_. Is the patch otherwise ok for trunk? What about the tuple part?
