220 29880 <15884364-3238-41c7-bc5a-aa5595a64ade@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: New smart pointer: CopyConstructible and CopyAssignable flavor of unique_ptr Date: Sat, 17 Dec 2016 10:04:47 -0800 (PST) Lines: 121 Approved: news@gmane.org Message-ID: <15884364-3238-41c7-bc5a-aa5595a64ade@isocpp.org> References: <67a9e9ed-8748-4098-a43b-33598b516464@isocpp.org> <20161217141109.GA22645@manuel-ThinkPad-L440.localdomain> <3df7e8eb-01a0-7804-f476-504b5a25a9fe@gmail.com> <20161217170428.GA10214@manuel-ThinkPad-L440.localdomain> <20161217171633.4919375.58072.21574@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_921_1947486817.1481997887862" X-Trace: blaine.gmane.org 1481997892 32127 195.159.176.226 (17 Dec 2016 18:04:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 18:04:52 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBQH42XBAKGQERMN3OPQ@isocpp.org Sat Dec 17 19:04:47 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIJLg-0007BI-Ue for gclcip-std-proposals@m.gmane.org; Sat, 17 Dec 2016 19:04:45 +0100 Original-Received: by mail-it0-f70.google.com with SMTP id x2sf22099274itf.6 for ; Sat, 17 Dec 2016 10:04:49 -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 :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=DiAce1se19oE7RxgDcI+ibZLUwVxHjNIV5u3+CDAuxs=; b=GXrB2udsd3WzA2LLUhjVg8MIn0LHo9kg30BjtW0B/PzW53WIU1vC85nT8B7V5kx9S2 RQ7t1ez16orD7Ii30XcSrSO3v3axzCParD7p9JBbu4kDEtlqNqI0YFtQe7lksBBnVWLL 8av/P9wyLpTZ61lKSsKZFxP3f4FeUqygmtfGKQQ7FP5ezrwt+Jan1bR+oZiBo8teihE3 h3vUE2BImZw+NwWa+8XjDj42/BX0frGF+2ms8cZyIsQOh1vczNNkFYXRsxoDob2KaME6 47LvsTRIF4ViQHd13twuRR7Fz0m2Zx01LFNPO9KG8H/iw1glWhs51bj1W5LuBQYaFsVB kB/Q== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=DiAce1se19oE7RxgDcI+ibZLUwVxHjNIV5u3+CDAuxs=; b=rdl98TQOjH/xCq74pkxAuoCnY8Z+GLSY6hUDF8dQ39cul0ZnUg3I2/Mq9fZIN1XMlS +EDpPdy2skgQ3N6foCCLVRQbCizsmNQVOcZk1es96xtXXXGI300RQVbjJmosy4VHYqI1 CoE3GylAvfGalG+Pu2h7spXsOej24a0zUUICPQcCrX5Klp0tm3pgya4yzpMkXGon85SF X9KHw/fopiRMvMmZw9cBYA/LOBfQpnjrE7+RAdY6sd+UYKkMa76BE7KFkce2w91HEbdm csBkS9fNsVWhAF3XkgY5PonpWZzwi4Iu0v7Z49mXtG4h+s8xsXaIEqrMscVJiFnKD20V wLPQ== 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=DiAce1se19oE7RxgDcI+ibZLUwVxHjNIV5u3+CDAuxs=; b=kJlvTxGpyvrv4VKSxYS2CBal5yNnc6gIHaVvesj1m2Dd/NxgHUlYSw8krHBvQX80sA IlfBu6z2/kI/16yEyrhzz6Zogkmy0JOF5QMDaYdPsjsDUu3AAkZ7LuO3ljClbSW/GqlH XGfv2X8ntc228gwM+Vwles6feIo32zdDSj7JxRW2TRQmzsrj9Qn76yYnnB916nFra8jH x2F7Uaw8TGBAheok61ev9X2ku2EVGIinLyrDkMTuGI8fJ5QyHzgLuagNe07d8Z5Bkdx+ 6X8RsFC1FlH78NIRwE1p4zS0dGuY+Z+hRn5i51aH/+vJMx6D3lJTrz/rwHBxOhngjlKn 5SoQ== X-Gm-Message-State: AIkVDXIib0n8YaTsbBwbQEfroKMhfvmDrL37fc1c0lSV1gn//U4ZAbZn5E1NlwUMP3R8CQ== X-Received: by 10.107.129.96 with SMTP id c93mr1865643iod.91.1481997889080; Sat, 17 Dec 2016 10:04:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.33.198 with SMTP id s64ls2135928otb.22.gmail; Sat, 17 Dec 2016 10:04:48 -0800 (PST) X-Received: by 10.157.42.66 with SMTP id t60mr436676ota.2.1481997888412; Sat, 17 Dec 2016 10:04:48 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:29880 Archived-At: ------=_Part_921_1947486817.1481997887862 Content-Type: multipart/alternative; boundary="----=_Part_922_1454908049.1481997887863" ------=_Part_922_1454908049.1481997887863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, December 17, 2016 at 12:48:28 PM UTC-5, Jonathan M=C3=BCller w= rote: > > On Dec 17, 2016 18:16, "Tony V E" > wrote= : > > > > Templates. Where you don't know if T has .clone(). Cloning in C++ is=20 > typically spelled with the copy-constructor.=20 > > > > But generic code would assume certain properties of a copy constructor,= =20 > this one does not have, as Sean Parent pointed out. > So copy constructing in generic code might be harmful.=20 > I don't think "might be harmful" is a good enough reason to not have the=20 type. After all, such copying behavior won't break most standard library types.= =20 `vector` will work as expected, as will `any`,=20 `optional`, `variant`, and so forth. The principle failing of `clone_ptr`'s copy operation is the lack of=20 equality between the copied objects (since equality is based on pointers,= =20 not `T`). So long as the template code does not care about equality after a= =20 copy, the template code ought to be fine. I think it's important to understand that `clone_ptr` is a solution to a=20 very specific problem, one that isn't exactly common. You shouldn't see a= =20 huge number of these pointers lying around. I'd say the biggest problem is that there's no way to conceptualize the=20 special nature of `clone_ptr`'s copy constructor. You can't write a=20 Concepts TS `requires` clause that says, "a copy constructor/assignment=20 shall ensure that the copied value is =3D=3D to the original." That's an=20 axiomatic distinction, not a syntactic one. And we don't have ways to=20 specify axioms or require based on them. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/15884364-3238-41c7-bc5a-aa5595a64ade%40isocpp.or= g. ------=_Part_922_1454908049.1481997887863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 12:48:28 PM UTC-5, Jonat= han M=C3=BCller wrote:

On Dec 17, 2016 18:16, "Tony V E" <tvan...@gmail.com&g= t; wrote:
>
> Templates. Where you don't know if T has .clone(). Cloning in C++ = is typically spelled with the copy-constructor.=C2=A0
>

But generic code would assume certain properties of a copy c= onstructor, this one does not have, as Sean Parent pointed out.

So copy= constructing in generic code might be harmful.

I don't think "might be harmful" is a good enough reason= to not have the type.

After all, such copying behavior won't br= eak most standard library types. `vector<clone_ptr>` will work as exp= ected, as will `any`, `optional<clone_ptr>`, `variant<clone_ptr>= ;`, and so forth.

The principle failing of `clone_ptr`'s copy op= eration is the lack of equality between the copied objects (since equality = is based on pointers, not `T`). So long as the template code does not care = about equality after a copy, the template code ought to be fine.

I t= hink it's important to understand that `clone_ptr` is a solution to a v= ery specific problem, one that isn't exactly common. You shouldn't = see a huge number of these pointers lying around.

I'd say the bi= ggest problem is that there's no way to conceptualize the special natur= e of `clone_ptr`'s copy constructor. You can't write a Concepts TS = `requires` clause that says, "a copy constructor/assignment shall ensu= re that the copied value is =3D=3D to the original." That's an axi= omatic distinction, not a syntactic one. And we don't have ways to spec= ify axioms or require based on them.

--
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/15884364-3238-41c7-bc5a-aa5595a64ade= %40isocpp.org.
------=_Part_922_1454908049.1481997887863-- ------=_Part_921_1947486817.1481997887862-- .