220 37460 <6122679d-7c00-4c10-a682-e57eb0a10abd@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: default assignment should be established by construction Date: Sun, 25 Mar 2018 08:18:10 -0700 (PDT) Lines: 121 Approved: news@gmane.org Message-ID: <6122679d-7c00-4c10-a682-e57eb0a10abd@isocpp.org> References: <58813920-b8f6-4e2f-83ed-c4c299792b62@isocpp.org> <298d8094-369b-46e3-8b4a-3714c8130cbb@isocpp.org> <1cde3d3e-b0e8-4a09-a0ef-569d7f5027dd@isocpp.org> <49d9bc4b-24fa-4bc1-afe1-98100fa81e8f@isocpp.org> <8d74a466-5781-4d02-abf8-c1681fb99871@isocpp.org> <2ae6f514-cef0-4a24-88ae-6b79b7ad1213@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9124_2062243192.1521991090148" X-Trace: blaine.gmane.org 1521990970 12706 195.159.176.226 (25 Mar 2018 15:16:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Mar 2018 15:16:10 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBM7333KQKGQEZMMHAYA@isocpp.org Sun Mar 25 17:16:06 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f07NN-0003C9-G4 for gclcip-std-proposals@m.gmane.org; Sun, 25 Mar 2018 17:16:05 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id u84sf11514901vke.13 for ; Sun, 25 Mar 2018 08:18:13 -0700 (PDT) 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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=mte724kg2YmE1pVVFh1TgLFhSp7IcXYV9TQBzkdVOro=; b=LbzS34D24PcDv4qohBstLdkRMdPy06evIq8lM6iZdUQ2C0wgQ4MhSRfQ7oJfBTBJI5 fViGEi2kkWfbIU0Jfcw2+UYz487Gi/v2AnwxxAHzoUhsvY5cRyybNyEVFZF5QF+wsakb ErSirGdDj0sDK+5m+ld6JRxMieTW3tBtKSSw5zrz9JH/zCKdNjnixTvRGtYzJ8l8mMsL 9pdZlzDQWAIW6o2nUSisbY6R0exlv7wBW+lV//lR1LiMOsxvfh3OhyOTcuyGGG78ruOd MyPw0629HidjDQ3Olbv+Rh+/JCTbCZubjnH4hq4/Sx6XuXfaY+pWTUgJACaH8RG3QtUe RUSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=mte724kg2YmE1pVVFh1TgLFhSp7IcXYV9TQBzkdVOro=; b=Vnsus2rzrWbJrhz6DyMQt80IMvNLDsj155LGqzNaYjc4KCbARQjwhxQZQW78P56F3D 6BW5gXIe0O848/Zd3BJBegG1Kms/wUEMvaFgr+DnpR0tNPZLBaTBLLrW4Bu9L5cWvI1u D2FkrJ9Wdh/mqn87flUquYTHhE3Obo+daSE9DkSCYu6rY5/q86nD1gZiz5Xq4qC35CPh Hb4Um95fbdcfW8VranEyID83hWAUcBQHkVR7+FaBZyAEUkJRuwRA4bZ3nki3JqTjFueb r7f4z1ohWkPFOowHC8a0tlZjRYLjL0gorSlocs9Qm+Vf7Fkt6yIahToCMGkGVOvHfz55 DQMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version: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=mte724kg2YmE1pVVFh1TgLFhSp7IcXYV9TQBzkdVOro=; b=A+t5fiWHdtMsSLFAn8OUHM4nhK74eFjHKvrkUOZgEeMXam/HZNgbGZ8YG1osa7HYl6 C7h6fOTDxSWXTuKaFXY90ci2UQDHEcpEacD7wIk3L4a24psoOtWc56xI4t2bQetXlcze jbZNBz0J+iTfFrY0yq+umiITXeFVBHqi6U+lg6yh8tKbWqFvwnhHJAqPleIOIvMyvdh6 htMkQh2FbtNREErD2YWNgknFUqw+16rwn35g12DolW4gcW7Ne4X3BgX6IvPpQp23sc7P kWEip5JBWU5eFKupImMMIrtrjxHu0lUXfWw8R4zvQgx718oGMIuCwE5FLpSGmn3DEG25 ETWQ== X-Gm-Message-State: AElRT7HopxDYsm6bhG7l+1ZmmTXnrlu5zNj/sHjt+Zasgx60TuVoHERJ x78s9fRwhDT6NsqPtfkl34ml+A== X-Google-Smtp-Source: AIpwx4/skwMz554ZKJTk78LBss3MWtOKYg6zmJW0nvAizp70AEqV1jv/4caQ35+EFckL+h4577ee5g== X-Received: by 10.31.148.130 with SMTP id w124mr399182vkd.80.1521991092273; Sun, 25 Mar 2018 08:18:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.67 with SMTP id j64ls7537083vke.21.gmail; Sun, 25 Mar 2018 08:18:10 -0700 (PDT) X-Received: by 10.31.158.83 with SMTP id h80mr4374075vke.9.1521991090828; Sun, 25 Mar 2018 08:18:10 -0700 (PDT) In-Reply-To: <2ae6f514-cef0-4a24-88ae-6b79b7ad1213@isocpp.org> X-Original-Sender: jmckesson@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:37460 Archived-At: ------=_Part_9124_2062243192.1521991090148 Content-Type: multipart/alternative; boundary="----=_Part_9125_1068172389.1521991090149" ------=_Part_9125_1068172389.1521991090149 Content-Type: text/plain; charset="UTF-8" On Sunday, March 25, 2018 at 9:54:27 AM UTC-4, Walt Karas wrote: > > On Saturday, March 24, 2018 at 7:42:47 PM UTC-5, Edward Catmur wrote: >> >> On Saturday, 24 March 2018 12:37:34 UTC, Walt Karas wrote: >> > On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote: >> > On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote: >> > >> > It seems that the current behavior (of suppressing the default >> assignment operator if there are const or reference data member) would have >> to be kept. >> > >> > So... what exactly is the purpose of this proposal? That's the thing I >> don't really understand; what does this allow us to do now that we could >> not before? >> > >> > >> > >> > It's a convenience. It think it would be very rare that it would not >> result in the desired behavior for the assignment operators. >> >> But how would this be any more convenient than the current behavior of >> memberwise assignment? > > > Because it also handles the case where the constructor is not the > default. For example, it's doing deep copying. > But deep copy assignment is a different operation from deep copy construction. In deep copy assignment, you *do not want* to allocate a new object the way you would have to for deep copy construction. It's silly to deallocate the currently managed object just to create a new one. Now yes, if you're managing some polymorphic type through a base class pointer, then you'll have to destroy and `clone` it either way. But that's hardly the only use case of deep copy semantics. There are plenty of deep copy types that know exactly what object they contain, and all of them will still have to provide an explicit copy/move assignment. I don't think this case is common enough to create a language change. You can just write the explicit copy/move assignment code for those cases where it crops up. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6122679d-7c00-4c10-a682-e57eb0a10abd%40isocpp.org. ------=_Part_9125_1068172389.1521991090149 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, March 25, 2018 at 9:54:27 AM UTC-4, Walt Karas = wrote:
On Satu= rday, March 24, 2018 at 7:42:47 PM UTC-5, Edward Catmur wrote:
On Saturday, 24 March 2018 12:37:34 UTC, Walt Ka= ras =C2=A0wrote:
> On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
> On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>=20
> It seems that the current behavior (of suppressing the default ass= ignment operator if there are const or reference data member) would have to= be kept.
>=20
> So... what exactly is the purpose of this proposal? That's the= thing I don't really understand; what does this allow us to do now tha= t we could not before?
>=20
>=20
>=20
> It's a convenience.=C2=A0 It think it would be very rare that = it would not result in the desired behavior for the assignment operators.

But how would this be any more convenient than the current behavior of = memberwise assignment?

Because it also hand= les the case where the constructor is not the default.=C2=A0 For example, i= t's doing deep copying.

But deep copy = assignment is a different operation from deep copy construction. In deep co= py assignment, you do not want to allocate a new object the way you = would have to for deep copy construction. It's silly to deallocate the = currently managed object just to create a new one.

Now yes, if you&#= 39;re managing some polymorphic type through a base class pointer, then you= 'll have to destroy and `clone` it either way. But that's hardly th= e only use case of deep copy semantics. There are plenty of deep copy types= that know exactly what object they contain, and all of them will still hav= e to provide an explicit copy/move assignment.

I don't think thi= s case is common enough to create a language change. You can just write the= explicit copy/move assignment code for those cases where it crops up.
<= /div>

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/6122679d-7c00-4c10-a682-e57eb0a10abd= %40isocpp.org.
------=_Part_9125_1068172389.1521991090149-- ------=_Part_9124_2062243192.1521991090148-- .