220 23725 article Path: news.gmane.org!not-for-mail From: Tomasz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Default swap/hash_value Date: Thu, 14 Jan 2016 13:02:10 -0800 (PST) Lines: 73 Approved: news@gmane.org Message-ID: References: <569582E5.1040108@wanadoo.fr> <2ca0a385-6399-4ac3-ba0d-609628ea4ec6@isocpp.org> <5697EAD8.8080104@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_911_1649533849.1452805330432" X-Trace: ger.gmane.org 1452805335 16828 80.91.229.3 (14 Jan 2016 21:02:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 21:02:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNPVXXG6IGBBU4Z4C2AKGQE5F3DTYA@isocpp.org Thu Jan 14 22:02:14 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJp25-0003FR-IT for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 22:02:13 +0100 Original-Received: by mail-yk0-f197.google.com with SMTP id v14sf761878358ykd.1 for ; Thu, 14 Jan 2016 13:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=GCukchIdu7MivzS907wgxe6qZMW9Tzb7QJ+epzPD5X4=; b=ST8Mpa+DkH39rM72bJtqb1bVXzUU+x4/4EcWwXhfBIyLkG9v5VR+KLSdB9B1WA7PVT Z7OFSNmV4+aDPH1xGfEV1JrcVWoP0AB12L9EUl4idLZGdjK/Omu/OyTEz8cHpYyMDZs/ 3NmFtCl+lgS0vzAm2JxFvC2NEg1XkjQF8bon8K4LBZDltICH1knqxaxF2HoSygGBAyc+ FIHH+4BZCIMHtLXIrq+T6lGXyRu8QiSuRg9YYkoAOZHcATwNH4Wyysrp6+PwYqy78Zt2 +33e/31baRUsLu5Uc/QbfsQ7cMjdrz8kz9D0NkpK9Rj1Boqtsw+EZXjn2ldbpzLrSa7a oCBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=GCukchIdu7MivzS907wgxe6qZMW9Tzb7QJ+epzPD5X4=; b=kQ7pR7REeFoCi+sd+O/d3E2+9Lr73Yqsm1B6lXy28DkIUvWk+62MCjDJ/dXO543j0A 2zWNAmuldZRHy5ogtheoXXdIe9t59zac8DN6QuS8JP7lQYo33gklszKVb7Dh250eMNot 5lTl6bPvyF8c6snWQXswxNVXThgmclZuoFM/yVG2fw3k8OdElB/Ch/KQUpVvxsqAl02N e7c86zPGFUvjuXZ2SEuL/3Z4mAN4EDl8N/OWisczySgCAKQmO70HVJcqLvAEzsCBJ2Gr mbXXuKQAU/bsz7XGrkVGxbVMVxs/VPeQowCJYRVIbEEoeH4HhmLiXOKJORjAU0Xjh6hB ginQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=GCukchIdu7MivzS907wgxe6qZMW9Tzb7QJ+epzPD5X4=; b=NcVnSikkLNSV53StqKN0ce5HNE8+Mh+JYop9haddj91hDGuUSSLLa8lCQGm6jwpWry WxAATohVpMgBmXGbnI6RQEGCW2kPzeGQVmMJ7FZa78n/ELkVBZBtnTuD6PmNWRhV0Y25 hHtQYTOKGEfSp3qaakubedENchXFZu5HXVdtcgLBrQJsGV8WNDSU6XS4AdN0iXxzxEOy c/E1V7vzJNpKmt92mG0eK7qSTnS2c5mruU0t/gTw/WcoehkFVWdfmJ3o+D80UIePtN+G c3Wt5sIwZgv6DG3hO1Q8L1L+BuJpWVh7377cGOv9UtGxeYLR96joh7h+7o1kRCOhSPoC 9OoA== X-Gm-Message-State: ALoCoQl2Pt+Aj1mepHjowE+18z3ZX7sHH+bVvzJR628C7Eyk91lxZ7c6GS1eyT6O7XWg9s1dAT3xU6lRtGlzETcn2pDe0P53Ug== X-Received: by 10.13.194.67 with SMTP id e64mr5400598ywd.17.1452805332186; Thu, 14 Jan 2016 13:02:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.39.65 with SMTP id n62ls638301ion.24.gmail; Thu, 14 Jan 2016 13:02:10 -0800 (PST) X-Received: by 10.50.178.173 with SMTP id cz13mr35364igc.10.1452805330977; Thu, 14 Jan 2016 13:02:10 -0800 (PST) In-Reply-To: <5697EAD8.8080104@wanadoo.fr> X-Original-Sender: tomaszkam@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:23725 Archived-At: ------=_Part_911_1649533849.1452805330432 Content-Type: multipart/alternative; boundary="----=_Part_912_520671806.1452805330433" ------=_Part_912_520671806.1452805330433 Content-Type: text/plain; charset=UTF-8 I see the reasoning between making the generation of hash_value depended on the generation of the operator==, as we must guarantee that o1 == o2 implies that hash_value(o1) == hash_value(o2). However I do not see any correlation between generation of swap and operator==. If move-constructor can be generated then we will have default implementation of swap (via std::swap). I think that you should generate swap for every class that have generated move operations (no user defined: copy/move constructor, copy/move assignment and destructor). I may be beneficial to have proper rule of six: i.e. non of following copy constructor/assigment, move constructor/assignment, swap, destructor is generated if at least on of them is defined. However this would be breaking change (as we may already have classes with swap, that uses compiler generated special functions), so I would stick to making swap depended on other five. Also the dependency on rule of five, would also lead of question if we should support defining swap on request via =default. -- --- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_912_520671806.1452805330433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see the reasoning between making the generation of hash_= value depended on the generation of the operator=3D=3D, as we must guarante= e that o1 =3D=3D o2 implies that hash_value(o1) =3D=3D hash_value(o2). Howe= ver I do not see any correlation between generation of swap and operator=3D= =3D. If move-constructor can be generated then we will have default impleme= ntation of swap (via std::swap). I think that you should generate swap for = every class that have generated move operations (no user defined: copy/move= constructor, copy/move assignment and destructor).

I may be benefic= ial to have proper rule of six: i.e. non of following copy constructor/assi= gment, move constructor/assignment, swap, destructor is generated if at lea= st on of them is defined. However this would be breaking change (as we may = already have classes with swap, that uses compiler generated special functi= ons), so I would stick to making swap depended on other five.

Also t= he dependency on rule of five, would also lead of question if we should sup= port defining swap on request via =3Ddefault.

--

---
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
------=_Part_912_520671806.1452805330433-- ------=_Part_911_1649533849.1452805330432-- .