220 25478 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: Thu, 7 Apr 2016 22:10:06 -0700 Lines: 391 Approved: news@gmane.org Message-ID: References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113dc8ba4cbd21052ff23566 X-Trace: ger.gmane.org 1460092209 9210 80.91.229.3 (8 Apr 2016 05:10:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 05:10:09 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBL72TS4AKGQEN3T2XZQ@isocpp.org Fri Apr 08 07:10:09 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aoOgK-00088I-Q9 for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 07:10:09 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id k184sf183600863ioe.3 for ; Thu, 07 Apr 2016 22:10:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender: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=gyq8ErL+7fJAWG41ECbY+ApnKJADSV9mlUdgkQuKZFM=; b=Qcu2pJOnNUqAj7NntiVFf5XW/ExLyR2wQNf2GWaT2Q7FJc667BlOMeGE9uzNtzvhfK xe425VDegBIwxv4PDAh7nOR3ahzdpsFF9yedRR890h6ZJyckfnNZiXacmrWQLWWIgbdu 2TbvWXdJc++A1qhK9RDsMTusZtDdd2fPSofkzYG5Kp0SaycMY2CDz1mwfG/bJ1DiX062 W6amzGO13dHXFrHhsiBKtmCsPVD0xIcmori/14A7gS/KqslgLS1M9bsbiPzeQhpTx8xQ GGniwozP80kjV4mLxWp0GnlZ09k5KukhoHZ8joyVuM///nQYIg2vNmwDip3jICc99YXA w50w== X-Gm-Message-State: AD7BkJLKwF3P+g79oH9+/NwdWIQnTgTaVUWctxb0gUZweqQTHjJhtrlp4BVJGg58o1Ogow== X-Received: by 10.107.128.22 with SMTP id b22mr4825762iod.10.1460092207800; Thu, 07 Apr 2016 22:10:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.84.72 with SMTP id k66ls2239978qgd.2.gmail; Thu, 07 Apr 2016 22:10:06 -0700 (PDT) X-Received: by 10.159.37.104 with SMTP id 95mr3190795uaz.85.1460092206709; Thu, 07 Apr 2016 22:10:06 -0700 (PDT) Original-Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com. [2607:f8b0:400c:c05::236]) by mx.google.com with ESMTPS id 103si2582341vkq.200.2016.04.07.22.10.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 22:10:06 -0700 (PDT) Received-SPF: pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c05::236 as permitted sender) client-ip=2607:f8b0:400c:c05::236; Original-Received: by mail-vk0-x236.google.com with SMTP id t129so39408391vkg.2 for ; Thu, 07 Apr 2016 22:10:06 -0700 (PDT) X-Received: by 10.31.33.137 with SMTP id h131mr3307137vkh.24.1460092206363; Thu, 07 Apr 2016 22:10:06 -0700 (PDT) Original-Sender: sean.middleditch@gmail.com Original-Received: by 10.159.41.103 with HTTP; Thu, 7 Apr 2016 22:10:06 -0700 (PDT) In-Reply-To: <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> X-Original-Sender: sean@middleditch.us 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::236 as permitted sender) smtp.mailfrom=sean.middleditch@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:25478 Archived-At: --001a113dc8ba4cbd21052ff23566 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 9:38 PM, wrote: > 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? Not with great specifics, or else I'd have written a paper on this. :) I'd imagine it'd have something to do with value categories. The ideal is to ensure that the compiler can statically detect moved-from objects and disable destructor execution and provide diagnostics when the variable is used, unless reinitialized explicitly. > > 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 They need no such thing. They use allocators. Allocators then need to use placement new (and never delete) in almost all cases, but that is deeply separate from most user code. Very few C++ users have written custom allocators. Or even custom containers. > the standard library without these features? You're forming strawmen. The standard library can be implemented purely with compiler intrinsics for all it matters in this context. > > 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. It's a partial solution (it solves a minor efficiency problem for vector and... what else? we've already gone over how it doesn't fix variant) and involves a new form of constructor, new defaulted function rules, and so on. It's a ton of work to add to the standardese and a ton of work to implement for exceedinly little pay-off and leaves us still needing _another_ solution for the other problems that make users (not just a handful of stdlib implementors) clamor for destructive move. It'd be like adding an incomplete version of move semantics that just added a new special syntax for move construction without also adding rvalue references or the extended value categories. Nobody has yet proven that we need to settle for a complicated half-solution. So let's not settle. :) > > 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. In which case, we just need a new type trait and some rules in the standard containers, and _zero_ new language features. Which game engine stdlib replacements have been doing for over a decade. :) > > If you have any ideas of how the proposed feature can be made safer, I would > love to hear about it. My very rough ideas would be to study value categories and rules and find the set of categories that allow for in-place object destruction and marking an object as "expired" so that the compiler knows it doesn't have to invoke destructors. This also ties into lifetimes, and possibly needs to integrate with a more nuanced notion of object lifetime in C++ (and hence possibly should be "bundled" with lifetime extension a la N4221 ) No, that's not a complete idea. I'm not saying I have a magic solution. It may well take _years_ to get any version of this right. If these things were easy or obvious, C++98 would have been a perfect language that never needed another revision ever again. :p > > However, this is not to be mistaken for a feature that end users should > directly use. Then it has no reason to be a heavy-weight feature requiring such extensive compiler support. If it's just for stdlib implementors and stdlib types, they can already offer relocation completely today as a point of QoI via private type traits purely in library code. 100% guarantee it, as I primarily use one that does just that. However, it turns out that "stdlib only" is not actually useful because (a) stdlib containers want to support user-provided types at full functionality, (b) some users do still need to write new containers given how anemic the stdlib is, and (c) relocation as you've proposed doesn't solve any particularly interesting or complicated problems worth the burden it imposes on implementors. You should either make your proposal much simpler pure-library affair or you should think bigger and try to solve a much larger set of the problems that destructive move / relocation could be solving. What you have now is heavy-weight but only solves a very mundane problem. > > > 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 a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscribe .. > To unsubscribe from this group and all its topics, 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 .. -- Sean Middleditch http://seanmiddleditch.com -- 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/CALQmNFgoV-Rg4T6%2BKqMFt6vNa7GCDpU%3DjVLRcnK4dDd%2BeBby8A%40mail.gmail.com. --001a113dc8ba4cbd21052ff23566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 7, 2016 at 9:38 PM, =C2=A0<isocppgroup@denisbider.com> wrote:
= > Hey Sean,
>
> if you would like to see move destruction / = relocation proposed in a safer
> form, do you have any ideas about wh= at that safer form would look like?

Not with great specifics, or els= e I'd have written a paper on this. :)

I'd imagine it'd = have something to do with value categories. The ideal is to ensure that the= compiler can statically detect moved-from objects and disable destructor e= xecution and provide diagnostics when the variable is used, unless reinitia= lized explicitly.

>
> You refer to that modern C++ discoura= ges direct use of new and delete. Well,
> yes, of course. But librari= es still need to use new and delete, as well as
> placement new, to i= mplement containers. How would you propose implementing

They need no= such thing. They use allocators. Allocators then need to use placement new= (and never delete) in almost all cases, but that is deeply separate from m= ost user code. Very few C++ users have written custom allocators. Or even c= ustom containers.

> the standard library without these features?<= br>
You're forming strawmen. The standard library can be implemented= purely with compiler intrinsics for all it matters in this context.
>
> 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 S= TL implementations, to
> solve problems that a lack of destructive mo= ve makes difficult.

It's a partial solution (it solves a minor e= fficiency problem for vector and... what else? we've already gone over = how it doesn't fix variant) and involves a new form of constructor, new= defaulted function rules, and so on. It's a ton of work to add to the = standardese and a ton of work to implement for exceedinly little pay-off an= d leaves us still needing _another_ solution for the other problems that ma= ke users (not just a handful of stdlib implementors) clamor for destructive= move.

It'd be like adding an incomplete version of move semanti= cs that just added a new special syntax for move construction without also = adding rvalue references or the extended value categories.

Nobody ha= s yet proven that we need to settle for a complicated half-solution. So let= 's not settle. :)

>
> 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. Langu= age users should use standard library types, and it's up
> to the= library types to implement relocators and move constructors.

In whi= ch case, we just need a new type trait and some rules in the standard conta= iners, and _zero_ new language features. Which game engine stdlib replaceme= nts have been doing for over a decade. :)

>
> If you have a= ny ideas of how the proposed feature can be made safer, I would
> lov= e to hear about it.

My very rough ideas would be to study value cate= gories and rules and find the set of categories that allow for in-place obj= ect destruction and marking an object as "expired" so that the co= mpiler knows it doesn't have to invoke destructors. This also ties into= lifetimes, and possibly needs to integrate with a more nuanced notion of o= bject lifetime in C++ (and hence possibly should be "bundled" wit= h lifetime extension a la N4221)

No, that's not a complete idea. I'm not sayi= ng I have a magic solution. It may well take _years_ to get any version of = this right. If these things were easy or obvious, C++98 would have been a p= erfect language that never needed another revision ever again. :p

<= /div>
>
> However, this is not to be mistaken for a feature th= at end users should
> directly use.

Then it has no reason to b= e a heavy-weight feature requiring such extensive compiler support. If it&#= 39;s just for stdlib implementors and stdlib types, they can already offer = relocation completely today as a point of QoI via private type traits purel= y in library code. 100% guarantee it, as I primarily use one that does just= that.

However, it turns out that "stdlib only" is not act= ually useful because (a) stdlib containers want to support user-provided ty= pes at full functionality, (b) some users do still need to write new contai= ners given how anemic the stdlib is, and (c) relocation as you've propo= sed doesn't solve any particularly interesting or complicated problems = worth the burden it imposes on implementors.

You should either make = your proposal much simpler pure-library affair or you should think bigger a= nd try to solve a much larger set of the problems that destructive move / r= elocation could be solving. What you have now is heavy-weight but only solv= es a very mundane problem.

>
>
> On Wednesday, April = 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:
>>
>&g= t;
>> On Apr 6, 2016 9:55 AM, <isocp...@denisbider.com> wrote:
>> >
>&= gt; > > The committee can mandate that standard library types all hav= e
>> > > relocators added where necessary but it can do no s= uch thing for
>> > > user types. However, the committee _doe= s_ want to allow variant
>> > > to be used with those same p= roblematic user types.
>> >
>> >
>> > W= ith respect to variant, it is already a major advantage of relocation
&g= t;> > that it can support:
>> >
>> > - except= ion-safe use of variant with non-nullable standard library types
>>= ; > - without requiring an existing std::list implementation to be throw= n away
>> > so it can be nothrow_move_constructible;
>>= ; >
>> > - exception-safe use of variant with future non-nul= lable types.
>>
>> But not "exception safe" for= other types, meaning that it still requires
>> the work around wi= th the valueless state. So we go from a "mostly never
>> empt= y" container to a "slightly more mostly never empty" contain= er. :)
>>
>> >
>> >
>> > Exist= ing problematic non-library types can of course still be supported,
>= > > if we're willing to lose the strong exception safety guarante= e 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
>&g= t; > > some object in an undefined state
>> >
>>= > I find this logic highly questionable. By this line of reasoning, we<= br>>> > should remove placement new, C-style casts, and manual mem= ory management, so
>> > that C++ might become a managed languag= e.
>>
>> Not at all, and that's quite the logical jum= p. 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) f= or back-compat are two very different things. :)
>>
>> Fo= r two, there are degrees of ease-of- misuse and not just a binary
>&g= t; 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 forcing users to
>> jump through hoops to convince the compi= ler of the validity of perfectly
>> valid code. It errs completely= on the side of safety. Nobody is (seriously)
>> advocating that f= or C++. Neither should we be advocating to adding more
>> C-level-= dangerous constructs to C++ without darn good reason. Half-fixing
>&g= t; variant and not actually fixing many _other_ major problems that destruc= tive
>> move could solve (e.g., accidentally using a moved-from pa= rameter instead of
>> the moved-to member in a class constructor).=
>>
>> For three, your feature proposal opens whole new c= lasses 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-pe= rformance situations like AAA games. A "good" destructive
>= > move should _reduce_ errors in existing code -- like accidentally usin= g
>> 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-misus= e auto_ptr with the much superior
>> unique_ptr. The potential per= formance improvements of move semantics were
>> icing on the cake.=
>>
>> Now let's be clear: the intent of relocation i= s 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 per= son and are obviously passionate about the issue. I
>> just strong= ly think that the proposal you currently have just isn't "there&qu= ot;
>> yet and needs more design iteration. :)
>>
>= > >
>
> --
> You received this message because you = are subscribed to a topic in the
> Google Groups "ISO C++ Standa= rd - Future Proposals" group.
> To unsubscribe from this topic, = visit
> https://groups.google.com/a/isocpp.org/= d/topic/std-proposals/jdY0hieE0E0/unsubscribe.
> To unsubscribe f= rom this group and all its topics, 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/4f31b= 957-05be-47cf-a1ca-03f33a9900c0%40isocpp.org.



--
Sea= n Middleditch
http://seanmiddledi= tch.com

--
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/CALQmNFgoV-= Rg4T6%2BKqMFt6vNa7GCDpU%3DjVLRcnK4dDd%2BeBby8A%40mail.gmail.com.
--001a113dc8ba4cbd21052ff23566-- .