220 2784 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: Sat, 9 Feb 2013 13:52:08 -0500 Lines: 373 Approved: news@gmane.org Message-ID: References: <713d1419-a642-408c-b3ba-44d1a17c2bb8@isocpp.org> <511227BD.9010306@gmail.com> <536643f8-e7bd-447c-8515-6829c42f8425@isocpp.org> <51127060.7010505@gmail.com> <8AB4D2A8-9E07-47C9-9F72-E5DD6D11B1FA@gmail.com> <5115987B.5000507@gmail.com> <778ABE6B-77D6-4349-BAC4-0AECA1F62CA0@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f22beb94c9b3804d54f2cb8 X-Trace: ger.gmane.org 1360435930 15671 80.91.229.3 (9 Feb 2013 18:52:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Feb 2013 18:52:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDP5Z6JXQHBBWVV3KEAKGQEORG3HSA@isocpp.org Sat Feb 09 19:52:32 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ee0-f70.google.com ([74.125.83.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U4FXK-00047g-R9 for gclcip-std-proposals@m.gmane.org; Sat, 09 Feb 2013 19:52:30 +0100 Original-Received: by mail-ee0-f70.google.com with SMTP id l10sf5459918eei.5 for ; Sat, 09 Feb 2013 10:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received: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=V+KQCJmD3YQO0qpTdGwDPGOd/2alMW4bon72HINt3vU=; b=IL6dbO6yfkcCKtZwmt8n3sqnEG5BxYgLTJXsWqIjyxg9wl6MnCVFL2tE+JGJwo8vgN 7C75Yhc7reEYoGtnqd8jdSxeKAOySZfdTWwXeXlffX45g7JRVmP1ghujrop6XcNTnfMh LXUVZm8w6gzl97dBqGDfRo72UeiQEnGuFO6ikwlO5M56yTsT15xL//rfDzd36ETH9fIN NEkgXdT5NXs/wLepf7MdfOCBfnNxEfCAelt4TVtlyqkvG6Xl70cvd4JbTbw7K4uWaxGr EqtGyktuDTragnMkU+DT+fc+4ZM0rcANHvFCniJ+123Tn8b46 X-Received: by 10.152.147.129 with SMTP id tk1mr2102993lab.0.1360435931114; Sat, 09 Feb 2013 10:52:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.108.103 with SMTP id hj7ls99858lab.86.gmail; Sat, 09 Feb 2013 10:52:09 -0800 (PST) X-Received: by 10.152.46.17 with SMTP id r17mr8407669lam.47.1360435929607; Sat, 09 Feb 2013 10:52:09 -0800 (PST) X-Received: by 10.152.46.17 with SMTP id r17mr8407667lam.47.1360435929585; Sat, 09 Feb 2013 10:52:09 -0800 (PST) Original-Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by mx.google.com with ESMTPS id ew4si8533332lbb.85.2013.02.09.10.52.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Feb 2013 10:52:09 -0800 (PST) Received-SPF: pass (google.com: domain of andrew.c.morrow@gmail.com designates 209.85.217.170 as permitted sender) client-ip=209.85.217.170; Original-Received: by mail-lb0-f170.google.com with SMTP id ge1so3782251lbb.29 for ; Sat, 09 Feb 2013 10:52:09 -0800 (PST) X-Received: by 10.152.147.130 with SMTP id tk2mr8420794lab.24.1360435929193; Sat, 09 Feb 2013 10:52:09 -0800 (PST) Original-Received: by 10.112.49.102 with HTTP; Sat, 9 Feb 2013 10:52:08 -0800 (PST) In-Reply-To: <778ABE6B-77D6-4349-BAC4-0AECA1F62CA0@gmail.com> 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.170 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:2784 Archived-At: --e89a8f22beb94c9b3804d54f2cb8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you everyone for your comments, and I apologize for the week long delay getting back to this thread. I'm going to try to summarize a bit and I have several questions as well. - As many pointed out, the underlying problem here is with ADL, not with swap. If 'noexcept(auto)', or Jeffrey's thought to give special lookup semantics to swap (or even all free functions in std), or some sort of 'using expression' were available, then std::is_swappable and std::is_nothrow_swappable would be unnecessary. However, a language level change will take some time. Is swap important enough to warrant special handling in the short term via a library extension, even if the value of is_[nothrow_]swappable is undermined by future language changes? - declval vs. declval: I think the argument in favor of declval was convincing to me. It does place some burden on the user , but I'd imagine users of the type traits facilities are able to deal with that burden. Unless there is a strong objection I will update my proposal along these lines. - Nikolay's comment on wording: I agree the wording is not sufficiently precise, but I'm not familiar enough with the idioms of the standard to do much better on my own so I did not attempt to perfect it. Suggestions on how to improve wording anywhere it is weak in the proposal would be much appreciated. - Nikolay's alternative implementation: I like the compactness of it, but the required changes to std::swap makes it less appealing to me. I do think writing the proposed implementation as if it were within ::std is a good idea, as it may reveal other problems, so I plan to update my proposal similarly. - Heterogeneous swap: My original implementation only handled homogeneous swap. I added support for heterogeneous swap because of 17.6.3.2 paragraph 1 which sets up "swappable with" in terms of heterogeneous types. However, 20.2 only specifies homogeneous swap. Howard's example with vector seems to make a case for supporting heterogeneous swap though. I'm happy to follow guidance here from those who understand this area better. - Symmetry for the heterogeneous case, assuming it is retained: If I'm understanding correctly, I think the symmetry constraint can be enforced easily for is_swappable: (ignoring possible declval vs declval changes here): In is_swappable_test: using test_type_tu =3D decltype(test(std::declval(), std::declval())); using test_type_ut =3D decltype(test(std::declval(), std::declval())); public: static constexpr bool value =3D !std::is_same::value && !std::is_same::value; The proposal language would need to be updated to capture the symmetry requirement as well but that seems straightforward. I don't think any changes need to be made to is_nothrow_swappable: I don't see that the standard says anything about the symmetrical overloads that make types "swappable" sharing a noexcept status, so for that case I think the argument order should be considered as provided by the caller. Admittedly it seems strange to have one overload be noexcept and the other not. - Overall is there a general thought on whether this proposal has enough merit to continue refining it? Thanks, Andrew On Sat, Feb 9, 2013 at 11:15 AM, Howard Hinnant w= rote: > > On Feb 8, 2013, at 11:43 PM, Tony V E wrote: > > > On Fri, Feb 8, 2013 at 7:29 PM, Mikael Kilpel=E4inen > > wrote: > >> 9.2.2013 0:36, Howard Hinnant kirjoitti: > >> > >>> For me here is the poster-child for heterogeneous swap: > >>> > >>> #include > >>> #include > >>> > >>> int main() > >>> { > >>> std::vector v(1); > >>> bool b =3D true; > >>> swap(b, v[0]); > >>> std::cout << v[0] << '\n'; > >>> } > >>> > >>> The standard doesn't say this should work, but imho the standard is > broken > >>> in that regard. It works in libc++ just as a personal expression of > >>> defiance. :-) Not sure if/where else. > >> > >> I agree something like this should work, but vector is rather > special > >> anyhow. The fix seems quite trivial for this specific case though, did > you > >> have some more generic > >> problem in mind which i just failed to see? > >> > >> > >>> > >>> I don't know of a case where a heterogeneous swap is useful for being > >>> explicitly heterogeneous. It is usually useful as trying to > masquerade as a > >>> homogeneous swap. > >>> > >> I think so too. Can you think of other "common" examples than > vector? > >> > >> > >> Mikael > >> > > > > > > If I can write (or similar): > > > > T t; > > U u; > > // swap them: > > T tmp =3D t; > > t =3D u; > > u =3D tmp; // or std::move(tmp) > > > > Then shouldn't I be able to swap them? > > Yes, but only if T and U are the same type or if you've written a custom > swap for T and U. The latter is how the swap(bool&, > vector::reference) example works. > > Howard > > -- > > --- > 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=3Den. > > > --=20 ---=20 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 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-proposa= ls/?hl=3Den. --e89a8f22beb94c9b3804d54f2cb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thank you everyone for your comments, and I= apologize for the week long delay getting back to this thread. I'm goi= ng to try to summarize a bit and I have several questions as well.

- As many pointed out, the underlying problem here is = with ADL, not with swap. If 'noexcept(auto)', or Jeffrey's thou= ght to give special lookup semantics to swap (or even all free functions in= std), or some sort of 'using expression' were available, then std:= :is_swappable and std::is_nothrow_swappable would be=A0unnecessary. However= , a language level change will take some time. Is swap important enough to = warrant special handling in the short term via a library extension, even if= the value of is_[nothrow_]swappable is undermined by future language chang= es?

- declval<T> vs. declval<T&>= ;: I think the argument in favor of declval<T> was convincing to me. = It does place some burden on the user , but I'd imagine users of the ty= pe traits facilities are able to deal with that burden. Unless there is a s= trong objection I will update my proposal along these lines.

- Nikolay's comment on wording: I agree= the wording is not sufficiently precise, but I'm not familiar enough w= ith the idioms of the standard to do much better on my own so I did not att= empt to perfect it. Suggestions on how to improve wording anywhere it is we= ak in the proposal would be much appreciated.

- Nikolay's alternative implementation:= I like the compactness of it, but the required changes to std::swap makes = it less appealing to me. I do think writing the proposed implementation as = if it were within ::std is a good idea, as it may reveal other problems, so= I plan to update my proposal similarly.

- Heterogeneous swap: My original implement= ation only handled homogeneous swap. I added support for heterogeneous swap= because of 17.6.3.2 paragraph 1 which sets up "swappable with" i= n terms of heterogeneous types. However, 20.2 only specifies homogeneous sw= ap. Howard's example with vector<bool> seems to make a case for s= upporting heterogeneous swap though. I'm happy to follow guidance here = from those who understand this area better.

- Symmetry for the heterogeneous case, assu= ming it is retained: If I'm understanding correctly, I think the symmet= ry constraint can be enforced easily for is_swappable: (ignoring possible d= eclval<T> vs declval<T&> changes here):=A0

In is_swappable_test:

<= /div>
=A0 =A0 =A0 =A0 = =A0 =A0 using test_type_tu =3D decltype(test<T, U>(std::declval<T&= amp;>(), std::declval<U&>()));
=A0 =A0 =A0 =A0 =A0 =A0 using te= st_type_ut =3D decltype(test<U, T>(std::declval<U&>(), std:= :declval<T&>()));

=A0 =A0 =A0 =A0 public:
=A0 =A0 =A0 =A0 =A0 =A0 static c= onstexpr bool value =3D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 !std::is_same<test_type_tu, swap_not= _found_type>::value &&
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = !std::is_same<test_type_ut, swap_not_found_type>::value;
=

The proposal language would need to be updated to= capture the symmetry requirement as well but that seems straightforward.

I don't think any changes need to be made to is_nothrow_swap= pable: I don't see that the standard says anything about the symmetrica= l overloads that make types "swappable" sharing a noexcept status= , so for that case I think the argument order should be considered as provi= ded by the caller. Admittedly it seems strange to have one overload be noex= cept and the other not.

- Overall is there a general thought on whe= ther this proposal has enough merit to continue refining it?

Thanks,
Andrew




On Sat, Feb 9, 2013 at 11:15 AM, Howard Hinnant <howard.hinnant@gmail.com> wrote:

On Feb 8, 2013, at 11:43 PM, Tony V E <tvaneerd@gmail.com> wrote:

> On Fri, Feb 8, 2013 at 7:29 PM, Mikael Kilpel=E4inen
> <mikael.kilpelainen= @gmail.com> wrote:
>> 9.2.2013 0:36, Howard Hinnant kirjoitti:
>>
>>> For me here is the poster-child for heterogeneous swap:
>>>
>>> #include <vector>
>>> #include <iostream>
>>>
>>> int main()
>>> {
>>> =A0 =A0 std::vector<bool> v(1);
>>> =A0 =A0 bool b =3D true;
>>> =A0 =A0 swap(b, v[0]);
>>> =A0 =A0 std::cout << v[0] << '\n';
>>> }
>>>
>>> The standard doesn't say this should work, but imho the st= andard is broken
>>> in that regard. =A0It works in libc++ just as a personal expre= ssion of
>>> defiance. :-) =A0Not sure if/where else.
>>
>> I agree something like this should work, but vector<bool> is= rather special
>> anyhow. The fix seems quite trivial for this specific case though,= did you
>> have some more generic
>> problem in mind which i just failed to see?
>>
>>
>>>
>>> I don't know of a case where a heterogeneous swap is usefu= l for being
>>> explicitly heterogeneous. =A0It is usually useful as trying to= masquerade as a
>>> homogeneous swap.
>>>
>> I think so too. Can you think of other "common" examples= than vector<bool>?
>>
>>
>> Mikael
>>
>
>
> If I can write (or similar):
>
> T t;
> U u;
> // swap them:
> T tmp =3D t;
> t =3D u;
> u =3D tmp; =A0// or std::move(tmp)
>
> Then shouldn't I be able to swap them?

Yes, but only if T and U are the same type or if you've wri= tten a custom swap for T and U. =A0The latter is how the swap(bool&, ve= ctor<bool>::reference) example works.

Howard

--

---
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-propo= sals+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=3Den.



--
 
---
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.
 
 
--e89a8f22beb94c9b3804d54f2cb8-- .