220 25470 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Wed, 6 Apr 2016 11:05:55 -0700 (PDT) Lines: 149 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/mixed; boundary="----=_Part_407_121844994.1459965956051" X-Trace: ger.gmane.org 1459965964 23900 80.91.229.3 (6 Apr 2016 18:06:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2016 18:06:04 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBNASW4AKGQEHSNVN3Y@isocpp.org Wed Apr 06 20:06:00 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1anrq3-0006hP-7A for gclcip-std-proposals@m.gmane.org; Wed, 06 Apr 2016 20:05:59 +0200 Original-Received: by mail-qk0-f197.google.com with SMTP id y19sf91128234qkb.0 for ; Wed, 06 Apr 2016 11:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=ofN2odtQuaAUB9niXI8HqAbST4WY6gWsFM9SR3rjeNE=; b=qbqyVrLcJ8yRQKtqfVNRsm/ABYwtUXhpLsfH2baNyuHfwLRo4Kf9n95GBhbnoyABsz KiqrVERT03awMe6LeBpkB4r42bRabCdvu1tOuFgV73c4vIYaGIj0eLbrtFHWF3bGQxI9 ISmheI5tO/HFEO8zLEi9AGEgXFZwBK91kn+11FyM1dXo3C7EEj+ZOaeLXfcIr/K0j7Ws pDQVXiHsX277Qh/n2NLM6lKEqhsfwgqH+g3z2mtqWaQqtraRmS2EBBWKiTWSdCJOyKpE 9Usj2qYphmf49R2WLAO1tmeREoGGqlItq6gsHbnzX4ky+kj5SOXXRWPWddY0EILAr82f 74Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=ofN2odtQuaAUB9niXI8HqAbST4WY6gWsFM9SR3rjeNE=; b=aYhEWx042M0tx7MNtwsmrhMILzwKq4R+LEeUNjsbUoNR7lMw1K61WxerARhlw5jMZ6 CeriW1/cbteUPL5R/sAdydPfSRHLduIE/Aaki1EK3ry7H7VDbVlj74yuGP/iaslUOIeG cvdOtL6iCYRIMsyP01RbPd3lbvNRKT/O3ARL1GJQgQZa6QoUMjF2E0o45WVEhuJ6aU8t kksKeOjLMXLZLFBsnqGnxCj7R8Idr83O+qbmYI7U4KordR0R6ZSboM0SkoOk1gl3WPco FoZ4fAQobCNZG0FVIRg6x9HEv1sLbCuQcg+eSHEqTcY1W0ap8vyXnePPIbiREDO7F7dD Wdgg== 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:cc: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=ofN2odtQuaAUB9niXI8HqAbST4WY6gWsFM9SR3rjeNE=; b=XTr8V0xCcC1BQWAHgjRR0PGFo+xLGMWZScXo7p5BErPGB9yQN71IwTMAhWqu0KCAa9 2V0Sd+f8y0GG5q/0bHcUg6NpMyN9EcatoepZI9tPJUgXeyblsvywnPlEleesCdW6Wier tQQb21NlYbCBTHRlN6jcFcr8ceJpUPoI9Dg6vd20L3ap3+cy5a2lkzMpoOWHKGYdOzLF WBZQWlEAQtzlrP/yKRVRlx86gadevxWQXIFtY4qtR0aVSV7et0MgBP2af+z4omIo30Na tgXGR/Qo7QcCbdcg5EggJck4+YGZQrXUZ/tZuTeSUmDDIR8sRzxVQ1VDuvycnY3x9HIW DpGw== X-Gm-Message-State: AD7BkJIvDSDqb1K3WmCUe+Ze5Jwsc2oofcN2L2sczxEwLFNgGSalhEfVNLfnHbYk6zMY2g== X-Received: by 10.129.75.86 with SMTP id y83mr13592791ywa.23.1459965958322; Wed, 06 Apr 2016 11:05:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.55.70 with SMTP id q6ls556777igp.43.gmail; Wed, 06 Apr 2016 11:05:57 -0700 (PDT) X-Received: by 10.50.160.40 with SMTP id xh8mr569293igb.7.1459965957048; Wed, 06 Apr 2016 11:05:57 -0700 (PDT) In-Reply-To: <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> X-Original-Sender: jmckesson@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:25470 Archived-At: ------=_Part_407_121844994.1459965956051 Content-Type: multipart/alternative; boundary="----=_Part_408_329220491.1459965956052" ------=_Part_408_329220491.1459965956052 Content-Type: text/plain; charset=UTF-8 On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, 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 > > 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. > > 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. > In which case, variant will still need to have a valueless state in order to support such types. Which means that, at the end of the day, "relocation" doesn't solve the problem. Indeed, P0308 doesn't seem to recognize that its own solution doesn't solve the problem either. Because the implicit conversions on parameters given to `emplace`-style assignment operations can throw as well. So even with types that are noexcept moveable, you can still wind up with a valueless variant. > 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. > No, that line of reasoning doesn't follow at all. There is absolutely no reason why we can't come up with a way to abscond with an object's resources and destroy it in the same action. Indeed, this forum is practically littered with ideas just like your "relocation" stuff. Such discussions call the idea "destructive move" or something similar. But overall, it's the same basic idea: abscond with resources and destroy the object. A great deal of discussion has taken place about ensuring that movement and destruction happen as a single action, to ensure that you don't leave objects broken. Hence the term "destructive move": the object is moved from and *destroyed*. I personally prefer that idea to what is basically just another form of "move, but I really *really* mean it this time." After all, the reason why move is problematic is that you're allowed to talk to the object later, so you have to deal with what the object's state is after the move. If you destroy the object as it is being moved from, then you don't have this problem. My overall point is that unsafety is not a requirement of resolving this problem. So there's no reason to use an unsafe idea when there are safer alternatives. -- 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/c4034cda-9ea4-4855-b718-6ed7b1f1d7c2%40isocpp.org. ------=_Part_408_329220491.1459965956052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, = isocp...@denisbider.com wrote:
=

> The committee can mandate that standard library ty= pes 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 nothro= w_move_constructible;

- exception-safe use of variant with future n= on-nullable types.


Existing problematic non-library = types can of course still be supported, if we're willing to lose the st= rong exception safety guarantee in that case. I'm not sure there is a s= ilver bullet that can avoid that.

In which= case, variant will still need to have a valueless state in order to suppor= t such types. Which means that, at the end of the day, "relocation&quo= t; doesn't solve the problem.

Indeed, P0308 doesn't seem to = recognize that its own solution doesn't solve the problem either. Becau= se the implicit conversions on parameters given to `emplace`-style assignme= nt operations can throw as well. So even with types that are noexcept movea= ble, you can still wind up with a valueless variant.

> W= ith your proposal, it's way too easy to accidentally leave
> some= object in an undefined state

I find this logic hi= ghly questionable. By this line of reasoning, we should remove placement ne= w, C-style casts, and manual memory management, so that C++ might become a = managed language.

No, that line of reasoni= ng doesn't follow at all.

There is absolutely no reason why we c= an't come up with a way to abscond with an object's resources and d= estroy it in the same action. Indeed, this forum is practically littered wi= th ideas just like your "relocation" stuff. Such discussions call= the idea "destructive move" or something similar. But overall, i= t's the same basic idea: abscond with resources and destroy the object.= A great deal of discussion has taken place about ensuring that movement an= d destruction happen as a single action, to ensure that you don't leave= objects broken.

Hence the term "destructive move": the ob= ject is moved from and destroyed. I personally prefer that idea to w= hat is basically just another form of "move, but I really really mean it this time." After all, the reason why move is problematic is= that you're allowed to talk to the object later, so you have to deal w= ith what the object's state is after the move. If you destroy the objec= t as it is being moved from, then you don't have this problem.

M= y overall point is that unsafety is not a requirement of resolving this pro= blem. So there's no reason to use an unsafe idea when there are safer a= lternatives.

--
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/c4034cda-9ea4-4855-b718-6ed7b1f1d7c2= %40isocpp.org.
------=_Part_408_329220491.1459965956052-- ------=_Part_407_121844994.1459965956051-- .