220 3071 article Path: news.gmane.org!not-for-mail From: "Andrew C. Morrow" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A proposal to add swap traits to the standard library Date: Tue, 12 Mar 2013 20:16:46 -0400 Lines: 221 Approved: news@gmane.org Message-ID: References: <6c1f8dc8-faaa-4b25-aea9-5dbe95bde4d4@isocpp.org> <489b9128-09ba-48b6-a18e-965636e9a072@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f22beb951c5a904d7c352b4 X-Trace: ger.gmane.org 1363133808 16152 80.91.229.3 (13 Mar 2013 00:16:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Mar 2013 00:16:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDP5Z6JXQHBB34K76EQKGQEGYUTE2Q@isocpp.org Wed Mar 13 01:17:13 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-bk0-f69.google.com ([209.85.214.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UFZNW-0002lF-Ci for gclcip-std-proposals@m.gmane.org; Wed, 13 Mar 2013 01:17:10 +0100 Original-Received: by mail-bk0-f69.google.com with SMTP id q16sf318408bkw.8 for ; Tue, 12 Mar 2013 17:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:received-spf:mime-version :x-received:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:list-subscribe:list-unsubscribe:content-type; bh=DF6iU/rUU+aAJzoHyCqbejwO1KgXs9i1HJkRJODLEJs=; b=NSDI5tAXKy6X4UhNVN2IiRQLJu+pASPN++wFS5KHpnX977+ZB0rpvEU8DH6G9vVA4p 4tHoubNeDq/wjFHKGJEb5Mdl4mUucYdJdS0sblFsHrhoZz99TyAA+96VmEDpcldEA+jE j8JqXQmLt9ACwAy4yK8beFNmVKK1fNbEA9SRmNevFKa4bce585OZboRfRLr1EBoHpvdV 7MgUXy3ESwrvljLfOODp5GfkXpQrcPkE5+u/FRgQSY7d8r8091SS/2GfBl21eDvvbvoQ LXGGTAI9mrcNCuh9Zp6OacDW0UdgXRgI6cvkC7SyujiWwf1YI3hQS8KK9A13tk4jFxzm X-Received: by 10.112.10.197 with SMTP id k5mr2148096lbb.16.1363133807430; Tue, 12 Mar 2013 17:16:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.105.35 with SMTP id gj3ls119920lab.9.gmail; Tue, 12 Mar 2013 17:16:46 -0700 (PDT) X-Received: by 10.152.104.36 with SMTP id gb4mr15859011lab.13.1363133806695; Tue, 12 Mar 2013 17:16:46 -0700 (PDT) Original-Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mx.google.com with ESMTPS id fx2si8574423lbb.265.2013.03.12.17.16.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 17:16:46 -0700 (PDT) Received-SPF: pass (google.com: domain of andrew.c.morrow@gmail.com designates 209.85.217.172 as permitted sender) client-ip=209.85.217.172; Original-Received: by mail-lb0-f172.google.com with SMTP id n8so469725lbj.31 for ; Tue, 12 Mar 2013 17:16:46 -0700 (PDT) X-Received: by 10.152.147.130 with SMTP id tk2mr15794412lab.24.1363133806526; Tue, 12 Mar 2013 17:16:46 -0700 (PDT) Original-Received: by 10.112.80.67 with HTTP; Tue, 12 Mar 2013 17:16:46 -0700 (PDT) In-Reply-To: <489b9128-09ba-48b6-a18e-965636e9a072@isocpp.org> X-Original-Sender: andrew.c.morrow@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of andrew.c.morrow@gmail.com designates 209.85.217.172 as permitted sender) smtp.mail=andrew.c.morrow@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:3071 Archived-At: --e89a8f22beb951c5a904d7c352b4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 12, 2013 at 6:22 PM, Nikolay Ivchenkov wrote: > On Wednesday, March 13, 2013 1:55:58 AM UTC+4, Nikolay Ivchenkov wrote: >> >> I still don't see any useful applications of such is_swappable. It >> doesn't answer whether the provided argument(s) is/are swappable, even >> roughly. A call to the general unconstrained version of std::swap, where >> both arguments are lvalues of the same type, will be always well-formed. If >> you don't want to change the declaration of std::swap, you can introduce >> some constrained surrogate for it and construct the candidate set from the >> surrogate and versions found by ADL: >> > > Sorry, I didn't consider this idea properly. Such implementation isn't > correct, because the general std::swap can conflict with such surrogate > (e.g. we will get value false on std::string *&). Any other surrogate, that > would be less specialized than the general std::swap, can potentially > conflict with a user-defined template. So, I see only one viable solution: > the general std::swap should be constrained. > > -- > > You raise a good point. I think I had not really grasped what you were saying the first time. You are correct that is_swappable is flawed in that it will sometimes return true_type, even though the swap expression wouldn't actually compile, unless std::swap is constrained as well. Your 'y1' type in your linked example demonstrates that. I actually hadn't noticed while experimenting with it because libc++ does in fact constrain its swap. However, I still need something that tells me "the expression 'swap(a,b)' is legal when unevaluated", because I need to avoid building that expression if it is illegal when I am trying to query for the noexcept status in the implementation of is_nothrow_swappable. And I think there is agreement that is_nothrow_swappable is useful. Also, is_swappable does capture some useful information, such as the symmetry requirement for heterogeneous swap. But clearly this is bad in the case where swap is not constrained: #include struct X { X& operator=(X const&) = delete; }; static if (std::is_swappable::value) { X x1, x2; using std::swap; // may confusingly fail to compile if swap is unconstrained swap(x1, x2); } Would renaming it to something with weaker implications improve the situation? std::is_swap_expressible? std::has_swap_overloads? Another option would be to eliminate std::is_swappable entirely and only retain std::is_nothrow_swappable, which is the true goal of the proposal anyway. Also, while working with your test code, I realized there was an issue in my example implementation. My version of std::is_swappable (note the lack of '&') derived from true_type, rather than false_type as it should, due to: template static auto __test(__V1 __v1, __V2 __v2) -> decltype(swap(__v1, __v2)); I believe the correct implementation is template static auto __test(__V1&& __v1, __V2&& __v2) -> decltype(swap(std::forward<__V1>(__v1), std::forward<__V2>(__v2))); I've pushed an update to the proposal with this change. Latest revision is here: http://acmorrow.github.com/cpp-proposals/swap_traits.html Given that the submission deadline is Friday, any thoughts on how to resolve the issues with std::is_swappable or comments on the above change to the example implementation would be much appreciated. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en. --e89a8f22beb951c5a904d7c352b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 12, 2013 at 6:22 PM, Nikolay Ivchenkov &l= t;mk.ivchenkov@= gmail.com> wrote:
On Wednesday, March 13, 2013 1:55:58 AM = UTC+4, Nikolay Ivchenkov wrote:
I still don't see any useful applications of such is_swappable. It does= n't answer whether the provided argument(s) is/are swappable, even roug= hly. A call to the general unconstrained version of std::swap, where both a= rguments are lvalues of the same type, will be always well-formed. If you d= on't want to change the declaration of std::swap, you can introduce som= e constrained surrogate for it and construct the candidate set from the sur= rogate and versions found by ADL:

Sorry, I didn't consider this idea properly= .. Such implementation isn't correct, because the general std::swap can = conflict with such surrogate (e.g. we will get value false on std::string *= &). Any other surrogate, that would be less specialized than the genera= l std::swap, can potentially conflict with a user-defined template. So, I s= ee only one viable solution: the general std::swap should be constrained.

--
=A0

You raise a good = point. I think I had not really grasped what you were saying the first time= .. You are correct that is_swappable is flawed in that it will sometimes return true_type, even though the= swap expression wouldn't actually compile, unless std::swap is constra= ined as well. Your 'y1' type in your linked example demonstrates th= at. I actually hadn't noticed while experimenting with it because libc+= + does in fact constrain its swap.

However, I still need something that tells = me "the expression 'swap(a,b)' is legal when unevaluated"= , because I need to avoid building that expression if it is illegal when I = am trying to query for the noexcept status in the implementation of is_nothrow_swappable. And I think the= re is agreement that is_nothrow_swapp= able is useful. Also, is_swapp= able does capture some useful information, such as the symmetry requ= irement for heterogeneous swap.

But clearly this is bad in the case where s= wap is not constrained:

#include <swap_traits>

struct X {
=A0 X& operator=3D(X const&) =3D delete= ;
};
=
static if (std::is_swappable<X>::value) = {
=A0 X x1, x2;
=
=A0 using std::swap;
=A0 // may confusin= gly fail to compile if swap is unconstrained
=A0 swap(x1, x2);
}

Would renaming it to something wit= h weaker implications improve the situation?

std::is_swap_expressible<T, U=3DT>?
std::has_swap_ove= rloads<T, U=3DT>?

Another option= would be to eliminate std::is_swappable entirely and only retain std::is_n= othrow_swappable, which is the true goal of the proposal anyway.

Also, while working with your test code, I = realized there was an issue in my example implementation. My version of std= ::is_swappable<int, int> (note the lack of '&') derived f= rom true_type, rather than false_type as it should, due to:

= =A0 =A0 template<typename __V1, typename __V2>
=A0 =A0 static auto __test(__V1 __v1, __V2= __v2) -> decltype(swap(__v1,=A0__v2));

I believe the correct implementation = is

=A0 =A0 template<typename __V1, typename __V2>
=A0 =A0 static auto __test(__V1&&= amp; __v1, __V2&& __v2) -> decltype(swap(std::forward<__V1>= ;(__v1),=A0std::forward<__V2>(__v2)));

I've pushed an update to the proposal with th= is change. Latest revision is here:

http://= acmorrow.github.com/cpp-proposals/swap_traits.html

Given that the submission deadline is= Friday, any thoughts on how to resolve the issues with std::is_swappable o= r comments on the above change to the example implementation would be much = appreciated.=A0


--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-pro= posals/?hl=3Den.
 
 
--e89a8f22beb951c5a904d7c352b4-- .