220 25475 article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Wed, 6 Apr 2016 21:45:07 -0700 Lines: 176 Approved: news@gmane.org Message-ID: 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/alternative; boundary=001a1141855a213891052fddbe90 X-Trace: ger.gmane.org 1460004315 12164 80.91.229.3 (7 Apr 2016 04:45:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2016 04:45:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBVGLS64AKGQECLGAKZI@isocpp.org Thu Apr 07 06:45:14 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ao1ob-0000u9-RE for gclcip-std-proposals@m.gmane.org; Thu, 07 Apr 2016 06:45:10 +0200 Original-Received: by mail-qg0-f69.google.com with SMTP id t38sf70300208qge.3 for ; Wed, 06 Apr 2016 21:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=1EXVfWmHdkRnUJn7lk2pIH1ldQUJnYZriS7pjlHm6ZE=; b=xMD2cc9SnzKcU+aZgkx3WJynEPk7rhzuCvEXeL4aYKIVU0qSA8bLxUZuZsxNXRPo85 seCwZHqZDg5Y/LZwiYVjd6EqNxUBiZmeBuoJ371SvGHB6x7KzT6z4GJDU4YtkYtHE37b PbbE3bmvF1SLUp+H/C7GaCEGmnvMk9l/0MTLJ6dcgg06gmT6NFKuGzHkouKMaLTWwuxa BAn7bPdAWuQ2KBJnvTGM96i2E+U6liuF4XLOSodLFQ0Cy/Y1bq6R1KbUriaGTNiyJMCr 3rp7mhe3hugZ2Qq8Xqwq5PA7i7BzDL6OsRnvPo5Q56zmf/Rq93CMxl1OzTJsp0BJmjJD O3Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=1EXVfWmHdkRnUJn7lk2pIH1ldQUJnYZriS7pjlHm6ZE=; b=fYUAtygAX8xkKOrKxYcAxgex7Tk70CErm0eq65FBpDjgqpPxE8F8BkXQHoU4Fxwa4N X6o0UbzQxnN5nqbuKBKYjhm/aFaFG/K4P5O0jxJ/to4XKwhfWiZXVYCfoigsJklsycqy NHeF3LRUsAfnLkGNqi1NQVis5m/gi/jwiEAjC8XXOBR9VxT3IgXRqRFYz8k8o3lqqXF5 GyT9pVHyWkbnTFBPl9RnRHxjQpmxzN9b9zKYH9wGf7UFQFD7UZ8B0cEdv4IWimoYihWF sRz0jqNtwTdelvmIPwiZIdvRnv2Nu6SwD2SUuQjQ4QzqfmAnCxN402NeuaFT1MU/cWOI zeFg== X-Gm-Message-State: AD7BkJItFCS/yDwiA7AKQz8k0cl9+GmGTdHg5vBR1xTLgoqdWlkVtKgNL04O+6lCbV/i2g== X-Received: by 10.140.159.136 with SMTP id f130mr650072qhf.3.1460004308940; Wed, 06 Apr 2016 21:45:08 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.82.233 with SMTP id h96ls1796284qgd.80.gmail; Wed, 06 Apr 2016 21:45:08 -0700 (PDT) X-Received: by 10.31.179.146 with SMTP id c140mr363612vkf.50.1460004307956; Wed, 06 Apr 2016 21:45:07 -0700 (PDT) Original-Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com. [2607:f8b0:400c:c05::234]) by mx.google.com with ESMTPS id 13si1332716vkq.158.2016.04.06.21.45.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 21:45:07 -0700 (PDT) Received-SPF: pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c05::234 as permitted sender) client-ip=2607:f8b0:400c:c05::234; Original-Received: by mail-vk0-x234.google.com with SMTP id e6so84828028vkh.2 for ; Wed, 06 Apr 2016 21:45:07 -0700 (PDT) X-Received: by 10.176.0.8 with SMTP id 8mr366341uai.67.1460004307677; Wed, 06 Apr 2016 21:45:07 -0700 (PDT) Original-Received: by 10.159.41.103 with HTTP; Wed, 6 Apr 2016 21:45:07 -0700 (PDT) In-Reply-To: <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> X-Original-Sender: Sean.Middleditch@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c05::234 as permitted sender) smtp.mailfrom=sean.middleditch@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:25475 Archived-At: --001a1141855a213891052fddbe90 Content-Type: text/plain; charset=UTF-8 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/CALQmNFja3Kt1XRR8S7Qr3rOktChVzuDGO7ZtSaQpsWaohU6wAA%40mail.gmail.com. --001a1141855a213891052fddbe90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 6, 2016 9:55 AM, <isocppgroup@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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALQmNFja3Kt1XRR8= S7Qr3rOktChVzuDGO7ZtSaQpsWaohU6wAA%40mail.gmail.com.
--001a1141855a213891052fddbe90-- .