220 25476 <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> article Path: news.gmane.org!not-for-mail From: isocppgroup@denisbider.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Thu, 7 Apr 2016 21:38:14 -0700 (PDT) Lines: 235 Approved: news@gmane.org Message-ID: <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_130_2079848649.1460090294215" X-Trace: ger.gmane.org 1460090299 15757 80.91.229.3 (8 Apr 2016 04:38:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 04:38:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBN7LTS4AKGQENLGZNZA@isocpp.org Fri Apr 08 06:38:18 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aoOBV-0004ly-V1 for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 06:38:18 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id v67sf139937622oie.0 for ; Thu, 07 Apr 2016 21:38:17 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=hGSzKo+79LCi2N/xtPal1bKmWRuy5aXKLp5OtjIcBjo=; b=0w9WH67QTUuVM4Oa0YkZNuJuZ5bNCxaOVMwSSTgy2DsKUVkqLjSy1ynP+cOCllj2Ot j3l+gSznxcnC3vslnPShW04SlDGiaOp8g3m9N+ik3HUdGPAVWNNCPI84q0PkbHokYpJK 0JVtDFf1cTe+OvtIW+LXwcOpSo/HHUCMqoB16A2+Ixowj6R8eSAWry5BE8ekmbmt+l7l OU2CtV6+7mptUedMsxFwH2U/bZNTL3ukHnJA3rKVH3JH+gyP2DwQyF5P0GPUW1zo4/nr BTLmQVcQPTwlcNVelPYyo7lLP0dl0v2zMlcJG+l4rHsHgjoa/pNSzRXKpryC/mfdg4zF z2Bw== 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: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=hGSzKo+79LCi2N/xtPal1bKmWRuy5aXKLp5OtjIcBjo=; b=GNy5YbR2a6hGGj1l8NesZTaffHGgwNVxSmm62dFBrTfspCuYCkFy3p17JnpRk8OMzu rAekBZE9CkfRsiN06GZX0za+hFxWqgL47nLgPgKwPzCzPkyJ0hdT+qvjp/oAB2az2QW8 sDt7znOijm8V3A3MyIuFxPGDaE1nClyweP0GHWE3QlPupGyCZmHPSIOUNWTF9kOuCbIj 0Lahs9ERKc9MG+FMmdKKTfbn93i+dkgVyBdqBkxmxqYyOgzlwyck2EHZPnspIrtSlxw8 bJDc6g3uauY5XBKW4+X3V4n/iwC05zTnxUzNkdBFPJTlu+fU3ZjRq7igU7WPfiIENRZQ m5PQ== X-Gm-Message-State: AD7BkJI1XHH9cgDk+/ENw8IyUlUqteW6LFLtao5DxUN1VMJguNPN/b4abpNmXcuc+giMig== X-Received: by 10.157.15.9 with SMTP id 9mr4385571ott.28.1460090296814; Thu, 07 Apr 2016 21:38:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.3.12 with SMTP id 12ls1089423iod.2.gmail; Thu, 07 Apr 2016 21:38:15 -0700 (PDT) X-Received: by 10.50.86.134 with SMTP id p6mr20849igz.9.1460090295478; Thu, 07 Apr 2016 21:38:15 -0700 (PDT) In-Reply-To: X-Original-Sender: isocppgroup@denisbider.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:25476 Archived-At: ------=_Part_130_2079848649.1460090294215 Content-Type: multipart/alternative; boundary="----=_Part_131_229753461.1460090294215" ------=_Part_131_229753461.1460090294215 Content-Type: text/plain; charset=UTF-8 Hey Sean, if you would like to see move destruction / relocation proposed in a safer form, do you have any ideas about what that safer form would look like? You refer to that modern C++ discourages direct use of new and delete. Well, yes, of course. But libraries still need to use new and delete, as well as placement new, to implement containers. How would you propose implementing the standard library without these features? It is not the intention of this Relocator proposal to be used directly by end users. The intention is that it would be used in STL implementations, to solve problems that a lack of destructive move makes difficult. Language users should not have to worry about invoking or implementing relocators, in much the same way they shouldn't have to worry about move constructors. Language users should use standard library types, and it's up to the library types to implement relocators and move constructors. If you have any ideas of how the proposed feature can be made safer, I would love to hear about it. However, this is not to be mistaken for a feature that end users should directly use. On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote: > > On Apr 6, 2016 9:55 AM, > wrote: > > > > > The committee can mandate that standard library types all have > > > relocators added where necessary but it can do no such thing for > > > user types. However, the committee _does_ want to allow variant > > > to be used with those same problematic user types. > > > > > > With respect to variant, it is already a major advantage of relocation > that it can support: > > > > - exception-safe use of variant with non-nullable standard library types > - without requiring an existing std::list implementation to be thrown away > so it can be nothrow_move_constructible; > > > > - exception-safe use of variant with future non-nullable types. > > But not "exception safe" for other types, meaning that it still requires > the work around with the valueless state. So we go from a "mostly never > empty" container to a "slightly more mostly never empty" container. :) > > > > > > > Existing problematic non-library types can of course still be supported, > if we're willing to lose the strong exception safety guarantee in that > case. I'm not sure there is a silver bullet that can avoid that. > > > > > > > With your proposal, it's way too easy to accidentally leave > > > some object in an undefined state > > > > I find this logic highly questionable. By this line of reasoning, we > should remove placement new, C-style casts, and manual memory management, > so that C++ might become a managed language. > > Not at all, and that's quite the logical jump. For one, your feature > doesn't actually exist yet, while those others do; adding unsafe features > and keeping old unsafe features (that we actually _do_ kinda-sorta > deprecate, e.g. the modern advice to never ever use new/delete or C-style > casts) for back-compat are two very different things. :) > > For two, there are degrees of ease-of- misuse and not just a binary > equation of assembly vs C# :) Rust for instance is a case of going too far > with protecting users from mistakes and going straight into forcing users > to jump through hoops to convince the compiler of the validity of perfectly > valid code. It errs completely on the side of safety. Nobody is (seriously) > advocating that for C++. Neither should we be advocating to adding more > C-level-dangerous constructs to C++ without darn good reason. Half-fixing > variant and not actually fixing many _other_ major problems that > destructive move could solve (e.g., accidentally using a moved-from > parameter instead of the moved-to member in a class constructor). > > For three, your feature proposal opens whole new classes of mistakes than > what we have today. The only mechanism even close to being as dangerous is > delete/free and modern C++ all but deprecates those features in user code, > even in high-performance situations like AAA games. A "good" destructive > move should _reduce_ errors in existing code -- like accidentally using > moved-from values -- rather than adding new ones. Performance alone isn't > good enough. Remember, rvalue references _real_ goal was to allow us to > replace things like the easy-to-misuse auto_ptr with the much superior > unique_ptr. The potential performance improvements of move semantics were > icing on the cake. > > Now let's be clear: the intent of relocation is good. We need someone > working on this, IMO. I'm more than happy to see you work on it; you seem > like a pretty bright person and are obviously passionate about the issue. I > just strongly think that the proposal you currently have just isn't "there" > yet and needs more design iteration. :) > > > > -- 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/4f31b957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org. ------=_Part_131_229753461.1460090294215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Sean,

if you=C2=A0would = like to see=C2=A0move destruction / relocation proposed in a safer form, do= you have any ideas about what that safer form would look like?
<= br>
You refer to that modern C++ discourages direct use of new an= d delete. Well, yes, of course. But libraries still need to use new and del= ete,=C2=A0as well as=C2=A0placement new,=C2=A0to implement containers. How = would you propose implementing the standard library without these features?=

It is not the intention of this Relocator proposa= l to be used directly by end users. The intention is that it would be used = in STL implementations, to solve problems that a lack of destructive move m= akes difficult.

Language users should not have to = worry about invoking or implementing relocators, in much the same way they = shouldn't have to worry about move constructors. Language users should = use standard library types, and it's up to the library types to impleme= nt relocators and move constructors.

If you have a= ny ideas of how=C2=A0the proposed feature=C2=A0can be made safer, I would l= ove to hear about it.

However, this is not to be m= istaken for a feature that end users should directly use.

On Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:<= /div>


On Apr 6, 2016 9:55 AM, <isocp...@denisbider.com> wrote:
>
> > The committee can mandate that standard library types all have > > relocators added where necessary but it can do no such thing for<= br> > > user types. However, the committee _does_ want to allow variant > > to be used with those same problematic user types.
>
>
> With respect to variant, it is already a major advantage of relocation= that it can support:
>
> - exception-safe use of variant with non-nullable standard library typ= es - without requiring an existing std::list implementation to be thrown aw= ay so it can be nothrow_move_constructible;
>
> - exception-safe use of variant with future non-nullable types.

= But not "exception safe" for other types, meaning that it still r= equires the work around with the valueless state. So we go from a "mos= tly never empty" container to a "slightly more mostly never empty= " container. :)

>
>
> Existing problematic non-library types can of course still be supporte= d, if we're willing to lose the strong exception safety guarantee in th= at case. I'm not sure there is a silver bullet that can avoid that.
>
>
> > With your proposal, it's way too easy to accidentally leave > > some object in an undefined state
>
> I find this logic highly questionable. By this line of reasoning, we s= hould remove placement new, C-style casts, and manual memory management, so= that C++ might become a managed language.

Not at all, and that's quite the logical jump. For one, = your feature doesn't actually exist yet, while those others do; adding = unsafe features and keeping old unsafe features (that we actually _do_ kind= a-sorta deprecate, e.g. the modern advice to never ever use new/delete or C= -style casts) for back-compat are two very different things. :)

For two, there are degrees of ease-of- misuse and not just a= binary equation of assembly vs C# :) =C2=A0Rust for instance is a case of = going too far with protecting users from mistakes and going straight into f= orcing users to jump through hoops to convince the compiler of the validity= of perfectly valid code. It errs completely on the side of safety. Nobody = is (seriously) advocating that for C++. Neither should we be advocating to = adding more C-level-dangerous constructs to C++ without darn good reason. H= alf-fixing variant and not actually fixing many _other_ major problems that= destructive move could solve (e.g., accidentally using a moved-from parame= ter instead of the moved-to member in a class constructor).

For three, your feature proposal opens whole new classes of = mistakes than what we have today. The only mechanism even close to being as= dangerous is delete/free and modern C++ all but deprecates those features = in user code, even in high-performance situations like AAA games. A "g= ood" destructive move should _reduce_ errors in existing code -- like = accidentally using moved-from values -- rather than adding new ones. Perfor= mance alone isn't good enough. Remember, rvalue references _real_ goal = was to allow us to replace things like the easy-to-misuse auto_ptr with the= much superior unique_ptr. The potential performance improvements of move s= emantics were icing on the cake.

Now let's be clear: the intent of relocation is good. We= need someone working on this, IMO. I'm more than happy to see you work= on it; you seem like a pretty bright person and are obviously passionate a= bout the issue. I just strongly think that the proposal you currently have = just isn't "there" yet and needs more design iteration. :)

>

--
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/4f31b957-05be-47cf-a1ca-03f33a9900c0= %40isocpp.org.
------=_Part_131_229753461.1460090294215-- ------=_Part_130_2079848649.1460090294215-- .