220 29886 <5eae5f16-e129-4c95-8001-fc73cc4f3d03@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:43:08 -0800 (PST) Lines: 164 Approved: news@gmane.org Message-ID: <5eae5f16-e129-4c95-8001-fc73cc4f3d03@isocpp.org> References: <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> <20161217182130.GA4347@manuel-ThinkPad-L440.localdomain> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1016_1976953854.1482000188759" X-Trace: blaine.gmane.org 1482000191 17736 195.159.176.226 (17 Dec 2016 18:43:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 18:43:11 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBPMO23BAKGQEOBSKYSI@isocpp.org Sat Dec 17 19:43:07 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIJwn-0003c4-QJ for gclcip-std-proposals@m.gmane.org; Sat, 17 Dec 2016 19:43:06 +0100 Original-Received: by mail-yw0-f199.google.com with SMTP id t11sf95767488ywe.3 for ; Sat, 17 Dec 2016 10:43:10 -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=jj5LLWyeb6Z+5h8SHkFR2KidTNgJaLYB2cikHYJMQJ0=; b=Jl+gVl6HViX2LhLiaw4vFC5F3ZtNWXS/TnRUo7fJjW7oWOerE8uoPZ0YBdtK2hX1kl 3uD6jmGw8fxhpmY6Fq3jFJJiqvgBksjCus2x5ClRHVRKyHhld3RtDanMYz5KQT9y6ZOb nZm57cFgn46HCOfWFunCLJRZlgqx5Hv4D+ytiSnCfr4L/R8jXVbrr7NdIbZ4w7bvx560 hH8TPnFMntpl3HPEULrH7SbT9q4vzZHkJDpGnT4AP75zlSilTG3zDcY4PS70VHzaRc4a pkjUOAdWZWrfGGkOvIcvBg9r+5PbGdjg9HDX7CmQaebOkLhZBoVLkiu6M1o/Hq9qT49Y dqKA== 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=jj5LLWyeb6Z+5h8SHkFR2KidTNgJaLYB2cikHYJMQJ0=; b=CkAZjYOnwZ4G7bkNDQ+VljYKhXI6+Vn/vWGV3xKJuadIMqx98ZCMXZCsXxDTp+P1Om oUCf6DV1gHS566BT36ziTRW0BB1l9hlrx/R5ngB4O4DvNuU8zQCxDTHXin4LrWQ0tZNZ eZgL9nwYgTKMGOsUQlvuBR+N9N3MGM15GBCyHMUWSL6gijs0IaUf3CGlnwAClDByBVBc Guegs00IuRDc/MTOfh0qR09Qy6uE0XS2Xzqxixz6+lhrfd/CI7w+/ZjnrUYkP1uc5P8v V51pOP5sdn709MEDim1/aBRlS891GNgqYi5EuKRFJVOqUp4w2yZrwAITPbiB2NRNP9Gu MWWg== 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=jj5LLWyeb6Z+5h8SHkFR2KidTNgJaLYB2cikHYJMQJ0=; b=rKvENuklrtva7poXDWGn3XN48N1V/ZZXejDGowO/XEdclPsZD79IeAGZIg2XFvVFTz FXA04URly2on40Qjk0ULbxdfqne2htxtXPKsMXluZwHe331/1flwMmuaPoSmbEUUayi8 WAEnoizq2Z90KZHnw0R45atcmWkMoPFiKltYNKf83NQPGSFFx/4W9UAc+BRBV3nFyo+F trQ+YYEh7O9pUkqIS7412wRJX0uGzOskZNF3bleKiSkU5NhCGoNaWLiAZqOYNbVR3RBs z/IzkvIwA7gcipNe4wG+ycQa+tnvS+yApm/KCVV3yhuP7YC3v4NgZFiQip43JRq351Q+ DMww== X-Gm-Message-State: AKaTC00EAOF8zJsqpCbSVNMOq5rF0bdvG9YuKbrXBLR8GIhFrog8RnDeXuxBaDDMHQlVjw== X-Received: by 10.13.217.87 with SMTP id b84mr2222016ywe.13.1482000190103; Sat, 17 Dec 2016 10:43:10 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.13.110 with SMTP id 101ls3866891oti.25.gmail; Sat, 17 Dec 2016 10:43:09 -0800 (PST) X-Received: by 10.157.27.9 with SMTP id l9mr500717otl.6.1482000189310; Sat, 17 Dec 2016 10:43:09 -0800 (PST) In-Reply-To: <20161217182130.GA4347@manuel-ThinkPad-L440.localdomain> 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:29886 Archived-At: ------=_Part_1016_1976953854.1482000188759 Content-Type: multipart/alternative; boundary="----=_Part_1017_1224326318.1482000188759" ------=_Part_1017_1224326318.1482000188759 Content-Type: text/plain; charset=UTF-8 On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel Bergler wrote: > > On Sat, Dec 17, 2016 at 10:04:47AM -0800, Nicol Bolas wrote: > > > > After all, such copying behavior won't break most standard library > types. > > `vector` will work as expected, as will `any`, > > `optional`, `variant`, and so forth. > > > > It would certainly work with the STL types, but I'm fairly certain you > might get very different results when using these in STL algorithms. With > some implementations references to the pointees might be preserved since > the algorithm doesn't copy the clone_ptr whereas others might perform a > copy, hence invalidating existing references or at least having them point > to a different object than the one returned from the algorithm. > Which is no different from passing a value type that gets copied, then expecting the copies to be modifying the original value. > > > I think it's important to understand that `clone_ptr` is a solution to > a > > very specific problem, one that isn't exactly common. You shouldn't > see a > > huge number of these pointers lying around. > > > I don't think "might be harmful" is a good enough reason to not have > the > > type. > > Together with the fact that the problem it tries to solve isn't common it > most > definitely is. If the type is very hard to use correctly and not really > needed > all that often then I see no reason to have it. > > > I'd say the biggest problem is that there's no way to conceptualize > the > > special nature of `clone_ptr`'s copy constructor. You can't write a > > Concepts TS `requires` clause that says, "a copy > constructor/assignment > > shall ensure that the copied value is == to the original." That's an > > axiomatic distinction, not a syntactic one. And we don't have ways to > > specify axioms or require based on them. > > The problem really is that it tries to act both as a pointer type which > would entail that after copying it the pointee is the same for both > pointers and at the same time it tries to be a object type where copying > creates distinct but equivalent instances. > But this is *exactly* how `any` works. The *only difference* is that `any` has no `operator==` overload. I'd be fine if it weren't considered a smart pointer type, even though it mostly is equivalent to `unique_ptr` in terms of interface. You could call it `clone_ptr_value` and have the comparison operators compare the stored value instead of the pointers. The main things are that it can adopt/manage/release pointers, and its copy semantics copy the object they point to. -- 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/5eae5f16-e129-4c95-8001-fc73cc4f3d03%40isocpp.org. ------=_Part_1017_1224326318.1482000188759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, December 17, 2016 at 1:22:19 PM UTC-5, Manuel= Bergler wrote:
On Sat, Dec 17,= 2016 at 10:04:47AM -0800, Nicol Bolas wrote:
>
> =C2=A0 After all, such copying behavior won't break most stand= ard library types.
> =C2=A0 `vector<clone_ptr>` will work as expected, as will `a= ny`,
> =C2=A0 `optional<clone_ptr>`, `variant<clone_ptr>`, an= d so forth.
>

It would certainly work with the STL types, but I'm fairly certain = you might get very different results when using these in STL algorithms. Wi= th some implementations references to the pointees might be preserved since= the algorithm doesn't copy the clone_ptr whereas others might perform = a copy, hence invalidating existing references or at least having them poin= t to a different object than the one returned from the algorithm.

Which is no different from passing a value type that gets c= opied, then expecting the copies to be modifying the original value.
=C2= =A0

> =C2=A0 I think it's important to understand that `clone_ptr` i= s a solution to a
> =C2=A0 very specific problem, one that isn't exactly common. Y= ou shouldn't see a
> =C2=A0 huge number of these pointers lying around.

> =C2=A0 I don't think "might be harmful" is a good en= ough reason to not have the
> =C2=A0 type.

Together with the fact that the problem it tries to solve isn't com= mon it most
definitely is. If the type is very hard to use correctly and not really= needed
all that often then I see no reason to have it.

> =C2=A0 I'd say the biggest problem is that there's no way = to conceptualize the
> =C2=A0 special nature of `clone_ptr`'s copy constructor. You c= an't write a
> =C2=A0 Concepts TS `requires` clause that says, "a copy const= ructor/assignment
> =C2=A0 shall ensure that the copied value is =3D=3D to the origina= l." That's an
> =C2=A0 axiomatic distinction, not a syntactic one. And we don'= t have ways to
> =C2=A0 specify axioms or require based on them.

The problem really is that it tries to act both as a pointer type which= would entail that after copying it the pointee is the same for both pointe= rs and at the same time it tries to be a object type where copying creates = distinct but equivalent instances.

But this is = exactly how `any` works. The only difference is that `any` has n= o `operator=3D=3D` overload.

I'd be fine if it weren't consi= dered a smart pointer type, even though it mostly is equivalent to `unique_= ptr` in terms of interface. You could call it `clone_ptr_value` and have th= e comparison operators compare the stored value instead of the pointers. Th= e main things are that it can adopt/manage/release pointers, and its copy s= emantics copy the object they point to.

--
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/5eae5f16-e129-4c95-8001-fc73cc4f3d03= %40isocpp.org.
------=_Part_1017_1224326318.1482000188759-- ------=_Part_1016_1976953854.1482000188759-- .