220 25472 <20f375ac-22f1-4af0-8321-91a9e7d135c2@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: Wed, 6 Apr 2016 11:54:15 -0700 (PDT) Lines: 205 Approved: news@gmane.org Message-ID: <20f375ac-22f1-4af0-8321-91a9e7d135c2@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_2129_1046542627.1459968855839" X-Trace: ger.gmane.org 1459968862 4249 80.91.229.3 (6 Apr 2016 18:54:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2016 18:54:22 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBWFWSW4AKGQEH5EIGBQ@isocpp.org Wed Apr 06 20:54:22 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ansao-0000e0-Rv for gclcip-std-proposals@m.gmane.org; Wed, 06 Apr 2016 20:54:19 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id d68sf95762314ywe.1 for ; Wed, 06 Apr 2016 11:54:18 -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=CBhrp3fK+Ia02dSm5fVCLWUAe+iW/eZHfndErLgTtFY=; b=eNNcI25hqD/TVDoIYDA0dQGznoSnrnYJcPrEPubOJWk56DEdzupbV5byywrkfLhHI8 3BZSsnAj6sHEH/pQeUZSNRuAPIeiw8RyK6vdIlYQtSg9mBM8OWx5SOw0ciFPxH+eDLgk Z0cYQlhMm1ueOzn7OmDLpJ+FA8a9rkMtRBjUHAJLHeOGEjclOtFVnh0wjqYdW1Vii4BJ 7kM1gaxZkjuPGUVgTwqqitNxXk6XdtspmdWtFPSukicVS9wW7xLJN12/cwjRILOsL0Vu MfM3jOakWV6uIWM0paQtUIZhsyUwDMYOBXTmOZE11e6J9liSod/ZAkPc23DFZRjfQpUl fueg== 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=CBhrp3fK+Ia02dSm5fVCLWUAe+iW/eZHfndErLgTtFY=; b=lU66LYMTAPW8jIDjYug3bmm+Hv0vcoyVM8FT15Cl2dbnfwV+9zbusTNQygEJHsCvC8 ffJ0jKLC2j0JGBfBfu9o2dHzXIfOQZNOIS3FtWpz1hq4avrRNAIIVMryD623I2R+CvJq Bur/C4vb1PmL6oAAjSt9685yce4ukbIQQBLK3ZLs4amR3bUKJTMsVQ+1dGw7ybjzc43D pDXctq+jH6d19wp+j6OoV6gp8+skHVgESwLT0fdZMZX3sQAPlssrfg3a3AMU0xc07BL7 kQbu24gjcravOUthVbza3JBlNZfjMny12CA308tnlYs6Q7P+Si+1YanBbKFMoVbb+5nG 7ljg== X-Gm-Message-State: AD7BkJLq0CL+UDXRhUHygNDeCtYUP9UU/VB4gqP0QQBfLMVkHmalJ6GnKHgpEwWRm1j1tg== X-Received: by 10.140.104.133 with SMTP id a5mr21354750qgf.16.1459968858039; Wed, 06 Apr 2016 11:54:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.20.79 with SMTP id 76ls376800iou.8.gmail; Wed, 06 Apr 2016 11:54:16 -0700 (PDT) X-Received: by 10.50.47.39 with SMTP id a7mr577835ign.2.1459968856628; Wed, 06 Apr 2016 11:54:16 -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:25472 Archived-At: ------=_Part_2129_1046542627.1459968855839 Content-Type: multipart/alternative; boundary="----=_Part_2130_74661097.1459968855840" ------=_Part_2130_74661097.1459968855840 Content-Type: text/plain; charset=UTF-8 Nicol, relocation *is* a destructive move. The relocator is a constructor for the new object, and destructor for the old object, rolled in one. I think this is spelled out quite clearly in the proposal. The old object does not continue to live after. Relocation and destructive move *are the same thing*. > In which case, variant will still need to have a valueless state in order to support such types. This cost can be borne by a specialization of the variant available to those who want a variant that is compatible with problematic types. Again, this is under the presumption that you want a variant that's compatible with problematic types where a variant can only be implemented unsafely. I find this a questionable presumption. > Because the implicit conversions on parameters given to `emplace`-style assignment operations can throw as well. P0308 does not solve this, but relocation does! Emplace construction can be done in a temporary, which is then relocated into the variant. On Wednesday, April 6, 2016 at 12:05:56 PM UTC-6, Nicol Bolas wrote: > > > 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/20f375ac-22f1-4af0-8321-91a9e7d135c2%40isocpp.org. ------=_Part_2130_74661097.1459968855840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nicol,

relocation is a destructive move. The relocator is a constructor for the new object, an= d destructor for the old object, rolled in one.

I = think this is spelled out quite clearly in the proposal. The old object doe= s not continue to live after.

Relocation and destr= uctive move are the same thing.


> In which case, variant will still need to have a valueless state= in order to support such types.

This cost can be = borne by a=C2=A0specialization of the variant available to those who want a= variant that is compatible with problematic types.

Again, this is under the presumption that you want a variant that's c= ompatible with problematic types where a variant can only be implemented un= safely.=C2=A0I find this a questionable presumption.


> Because the implicit conversions on parameters given= to `emplace`-style assignment operations can throw as well.

=
P0308 does not solve this, but relocation does! Emplace construc= tion can be done in a temporary, which is then relocated into the variant.<= /div>


On Wednesday, April 6, 2016 at 12:05:56 PM UTC= -6, Nicol Bolas wrote:
<= br>
On Wednesday, April 6, 2016 at 12:55:11 PM UTC-4, isocp...@denisb= ider.com wrote:

> Th= e committee can mandate that standard library types all have
> reloca= tors added where necessary but it can do no such thing for
> user typ= es. However, the committee _does_ want to allow variant
> to be used = with those same problematic user types.


With respec= t to variant, it is already a major advantage of relocation that it can sup= port:

- exception-safe use of variant with non-nul= lable standard library types - without requiring an existing std::list impl= ementation 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 b= e supported, if we're willing to lose the strong exception safety guara= ntee in that case. I'm not sure there is a silver bullet that can avoid= that.

In which case, variant will still n= eed to have a valueless state in order to support such types. Which means t= hat, at the end of the day, "relocation" doesn't solve the pr= oblem.

Indeed, P0308 doesn't seem to recognize that its own solu= tion 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 reasonin= g, we should remove placement new, C-style casts, and manual memory managem= ent, so that C++ might become a managed language.
<= div>
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&qu= ot; stuff. Such discussions call the idea "destructive move" or s= omething similar. But overall, it's the same basic idea: abscond with r= esources 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 &quo= t;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 r= eason why move is problematic is that you're allowed to talk to the obj= ect later, so you have to deal with what the object's state is after th= e move. If you destroy the object as it is being moved from, then you don&#= 39;t have this problem.

My overall point is that unsafety is not a r= equirement of resolving this problem. So there's no reason to use an un= safe idea when there are safer alternatives.

--
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/20f375ac-22f1-4af0-8321-91a9e7d135c2= %40isocpp.org.
------=_Part_2130_74661097.1459968855840-- ------=_Part_2129_1046542627.1459968855839-- .