Re: [v3 PATCH] LWG 2766, LWG 2749

[Jonathan Wakely <jwakely at redhat dot com>]

On 22/11/16 16:59 +0200, Ville Voutilainen wrote:
> On 22 November 2016 at 15:36, Jonathan Wakely <jwakely@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;


Yes, I noticed that :-)

> 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?

Yes, OK changing the top-level __not_s to operator!

I haven't reviewed the tuple part fully yet.