220 29885 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:25:44 -0800 (PST) Lines: 153 Approved: news@gmane.org Message-ID: 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> <15884364-3238-41c7-bc5a-aa5595a64ade@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_887_2075252224.1481999144442" X-Trace: blaine.gmane.org 1481999151 9606 195.159.176.226 (17 Dec 2016 18:25:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 18:25:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKMG23BAKGQE2OROKPQ@isocpp.org Sat Dec 17 19:25:42 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIJfx-0001A0-CZ for gclcip-std-proposals@m.gmane.org; Sat, 17 Dec 2016 19:25:41 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id p9sf80842085vkd.7 for ; Sat, 17 Dec 2016 10:25:46 -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=EXx94F8izX1YxoU6HTThkiXYSS5XFT9hkE4DTuunAhE=; b=HANXu07Z5X9RSoQ7tIZICG83rR+64+9A6b7RNWtFn++BjFc594G2cMSJDTR4NNp7jL mthVsSALIoX5bmdD29WnDLkgKg2V8e4nNE7LZmzHu+AQQIcKUELVFgXZkQqZWCqRadNa UPq/ZXRhqarJvY3UMPvqF420g2W6ydtEzaxQs5Pkfw8WtC610S6x+qt/b51jek2CZsm/ LdVxPgt0i9OsXAVl2/ta2q8gTdyEJj0aAS7N1ETXSc84mZCk0TK42XtkTgA85PiwwHPZ EI+q69AGOdaysbJQONWJKvZ/wH4mLnUPnCn+AwsluF3SYmwZnoWHUd5nyC1w9ZWV+1N7 00Xw== 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=EXx94F8izX1YxoU6HTThkiXYSS5XFT9hkE4DTuunAhE=; b=qt1QlvpILwadsNCfYgFJeuCAlk64T9yZVtjJD1D/P/tgVJI7nfUB/6OOrbgslczyPk CJ7uhciMESxjOtpphilLoAbwM1Z5PPws4g8znTPGXiNGKc3yxQNZpFirhtxTgPL9c+9x tJavvpWCKwRJbxg/12XSsQNZAIqpWLxcJZmuIkzhGzqWnVb5YF1DAea9GvR7X+hs5FFA 1CjZUz1Fks9ZVbwbJmiM5TJGTq1MVgQLj+p8T8Zq5iizgemYT0KGO6UHKZMkKrn67Zvn WLLfNpOIEx37EYvfs6bwk03QGvjQW5PHUGzWiktSN+pTmSaoqyfBl/W1/0Miw1V30Bex DU8w== 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=EXx94F8izX1YxoU6HTThkiXYSS5XFT9hkE4DTuunAhE=; b=JNe9zBtsldhgguoPvai05Xb9t2Y+LtIKaNmWSdWzNJcinDhfrN+BQUw4roe6z5xspK WzOH6C8Uwx7CB7M4Lka0s/EaDqexUBQ00vFuaW+9DRPqlZ9W7FBJUAzv10QCY2hHxTAQ rxrsB9u+eAlnrcIaJqgclz1mZiMBKHbxMSVk2WslNr+UVkemmbaR4g8WN4YFm6Gj/Kqw HIMCSmBS2OcGHJRn5t0hPmihZZcj0yRwtCEP9jlodjPJ3AdLLRipjWr2TCs9d0bLsQbI kl+7MRuTBs7Ban2Rt3tw4939sgq0V3DvK0OmHJzRWvLExK7fBpQ624+fxk3/bY1e6jPC vicA== X-Gm-Message-State: AKaTC03JKOG15r+KGopsjD9euHXLUgscTuG0GLQKgSjmU1MakJ2GZdngKhPyeCIyEtFCGw== X-Received: by 10.159.48.150 with SMTP id j22mr3553436uab.25.1481999145714; Sat, 17 Dec 2016 10:25:45 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.46.13 with SMTP id q13ls10530499otb.20.gmail; Sat, 17 Dec 2016 10:25:45 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr508570ote.8.1481999145008; Sat, 17 Dec 2016 10:25:45 -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:29885 Archived-At: ------=_Part_887_2075252224.1481999144442 Content-Type: multipart/alternative; boundary="----=_Part_888_1400561331.1481999144442" ------=_Part_888_1400561331.1481999144442 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, December 17, 2016 at 1:14:22 PM UTC-5, Jonathan M=C3=BCller wr= ote: > > On Dec 17, 2016 7:04 PM, "Nicol Bolas" >= =20 > wrote: > > > > I don't think "might be harmful" is a good enough reason to not have th= e=20 > type. > > I think it's a very compelling reason. I rather have types that can be=20 > used without thinking, because misuse is a compiler error. > C++ is not a safe language. =20 > > After all, such copying behavior won't break most standard library=20 > types. `vector` will work as expected, as will `any`,=20 > `optional`, `variant`, and so forth. > > All of these type work without copy constructing. > No, all of those types *can be used* without copy constructing. That's not= =20 the same thing. And it's not even true, because `any` has an explicit requirement that the= =20 type it stores be copy-constructible. So if you have your way, we wouldn't= =20 be able to put `clone_ptr` in an `any` at all. Indeed, that's one of the=20 most important demonstrations of why we need `clone_ptr`. =20 > The only reason you'd need copy constructing there is if you'd need to=20 > insert a copy or copy the container. The first one is very easy, just cal= l=20 > clone, the second requires a for loop. > Yes, and avoiding both of those is the point of `clone_ptr`. What's the point of using `vector` if you're going to have to explicitly=20 make a loop to copy it? It helps *nobody*; it makes your code bulkier and= =20 needlessly harder to read. All so that you have to call some member=20 function just to do the copy. =20 > > 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. > > Yeah, and that's why I can't really see a compelling use case for them. > I could say the same thing about `small_vector` or `intrusive_ptr`, but=20 that doesn't mean we shouldn't have one. --=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/b3a1aa29-394b-4930-80c6-2c217af65c52%40isocpp.or= g. ------=_Part_888_1400561331.1481999144442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 1:14:22 PM UTC-5, Jonath= an M=C3=BCller wrote:

On Dec 17, 2016 7:04 PM, "Nicol Bolas" <jmck...@gmail.com= > wrote:
>
> I don't think "might be harmful" is a good enough reason= to not have the type.

I think it's a very compelling reason. I rather have typ= es that can be used without thinking, because misuse is a compiler error.


C++ is not a safe language.
=C2=A0

> After all, such copying behavior won't break most s= tandard library types. `vector<clone_ptr>` will work as expected, as = will `any`, `optional<clone_ptr>`, `variant<clone_ptr>`, and so= forth.

All of these type work without copy constructing.


No, all of those types can be used without copy const= ructing. That's not the same thing.

And it's not even true, = because `any` has an explicit requirement that the type it stores be copy-c= onstructible. So if you have your way, we wouldn't be able to put `clon= e_ptr` in an `any` at all. Indeed, that's one of the most important dem= onstrations of why we need `clone_ptr`.
=C2=A0

The only reason you'd need copy= constructing there is if you'd need to insert a copy or copy the conta= iner. The first one is very easy, just call clone, the second requires a fo= r loop.


Yes, and avoiding both of those is the poi= nt of `clone_ptr`.

What's the point of using `vector` if you'= ;re going to have to explicitly make a loop to copy it? It helps nobody<= /i>; it makes your code bulkier and needlessly harder to read. All so that = you have to call some member function just to do the copy.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

> I think it's important to understand that `clone_pt= r` is a solution to a very specific problem, one that isn't exactly com= mon. You shouldn't see a huge number of these pointers lying around.

Yeah, and that's why I can't really see a compelling= use case for them.


I could say the same thing abo= ut `small_vector` or `intrusive_ptr`, but that doesn't mean we shouldn&= #39;t have one.

--
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/b3a1aa29-394b-4930-80c6-2c217af65c52= %40isocpp.org.
------=_Part_888_1400561331.1481999144442-- ------=_Part_887_2075252224.1481999144442-- .