220 25479 <30181f63-7189-494d-9294-3f8b8759308f@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 23:07:16 -0700 (PDT) Lines: 475 Approved: news@gmane.org Message-ID: <30181f63-7189-494d-9294-3f8b8759308f@isocpp.org> 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/mixed; boundary="----=_Part_150_1744017611.1460095636653" X-Trace: ger.gmane.org 1460095641 25517 80.91.229.3 (8 Apr 2016 06:07:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 06:07:21 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBFUVTW4AKGQEAE2ZXGQ@isocpp.org Fri Apr 08 08:07:21 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 1aoPZf-0002Mq-V1 for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 08:07:20 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id h6sf172491415ywc.3 for ; Thu, 07 Apr 2016 23:07:19 -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=zVswCqtFIgGemb7THOqnALZnt2Fvbxb4yq1pVnFllF4=; b=1dmi2q30im1rUgNG/06XuhQMUHqn81ZCgDpYnAJ5Z47KEsScQiqtDycNEq8eyfHKOM te1kodYKqbL36VxJehH5BahaMVZdWaArhR3T7SVX9b8AOyAwaXCEA1VkDvlb8j6/GIcV UXjVt+OF7NAaqND7U5hva3ImVTLgoW4PWmMkuQh0eAVohRkDQhHe3TX0KEIRzawzRRPd kfmfaOaFxgVCROLbRbglIHeknVB+obvzCOQl7AKRGO5jWTTtVFQar8ytGS0SDpiYT+cH WQBCPaZdVKlstmROTyc6l7h9yFVZ7XT8XBkCsRm76AA7lpYW5iD6WvUx1mE6Z9j3xYJ3 SGsA== 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=zVswCqtFIgGemb7THOqnALZnt2Fvbxb4yq1pVnFllF4=; b=ZQIv5ra0KvMH8RnDigv5n8ASWClWAf/7kdXiWuZjF/++HL3XUSR+j0uTJnG/qZGOuq 1MTj1OYXsQ8vBBSs4Hw7o4KNlniq5EprRaWyWzLc294irfbKmWoiW+cIqCnz+zy7fNvf 9kxxhLOZ4YKZ0SCyFOvXOJpWVVHvJNs4dGXJAR8IEMHUjeAfbudlR4Ul2ZtLx9vIiEVh UmSWaoc2oMNfLKaPblIX/guWVVQSrsBY7Bd2vAMzctDtn0iNAQpJvwyX+ij1aFZ2SItD SjycysCiShdhCDYbbqjIiKTB9uzaOeat6qXku/KFgBIJJu6P5ewE5wLfrOVeVLxGVd/d ZPIg== X-Gm-Message-State: AD7BkJKYXg67HQjxCfFYaN66vgEsZb1yTlPuWnZrDagJSn5eLDI/C1HGQuQL5T6kBQ42lw== X-Received: by 10.13.216.78 with SMTP id a75mr4406827ywe.22.1460095639031; Thu, 07 Apr 2016 23:07:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.163.13 with SMTP id m13ls1152190ioe.49.gmail; Thu, 07 Apr 2016 23:07:17 -0700 (PDT) X-Received: by 10.50.155.72 with SMTP id vu8mr25403igb.5.1460095637622; Thu, 07 Apr 2016 23:07:17 -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:25479 Archived-At: ------=_Part_150_1744017611.1460095636653 Content-Type: multipart/alternative; boundary="----=_Part_151_941910145.1460095636654" ------=_Part_151_941910145.1460095636654 Content-Type: text/plain; charset=UTF-8 Ah, Jesus. It seems to me C++ has become infested with people who call themselves "modern", but whose objective is to desperately try to divorce the language from its low-level origins, while ashamedly having to recognize that this cannot be done, because it would defeat the purpose of the language and make it useless for its primary role. You are now building this over-ambitious standard library monstrosity, which is trying to pretend that C++ can be a platform. But the role of C++ is not to *be* a platform. It is a tool for *building* platforms, and for building applications on top of existing platforms. I can honestly say I don't like what you're doing, and if you keep going in this direction, C++ will have to be replaced with something that serves its original purpose. Stop trying to make this a managed language, for god's sake. On Thursday, April 7, 2016 at 11:10:08 PM UTC-6, Sean Middleditch wrote: > 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-proposal...@isocpp.org . > > To post to this group, send email to std-pr...@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/30181f63-7189-494d-9294-3f8b8759308f%40isocpp.org. ------=_Part_151_941910145.1460095636654 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, Jesus.

It seems to me C+= + has become infested with people=C2=A0who call themselves "modern&quo= t;, but whose=C2=A0objective is to=C2=A0desperately try to divorce=C2=A0the= language=C2=A0from its low-level origins, while=C2=A0ashamedly having to= =C2=A0recognize that this cannot be done, because it would defeat the purpo= se of the language and make it useless for its primary role.

=
You are now building this over-ambitious standard library monstr= osity, which is=C2=A0trying to pretend that C++ can be a platform. But the= =C2=A0role of C++ is not to be a platform. It is a tool for bu= ilding platforms, and for building applications on top of existing pla= tforms.

I can honestly say I don't like what y= ou're doing, and if you keep going in this direction, C++ will have to = be replaced with something that serves its original purpose.

=
Stop trying to make this a managed language, for god's sake.=


On Thursday, April 7, 2016 at 11:10:08 PM UTC-6, Sean Mi= ddleditch wrote:
On Thu,= Apr 7, 2016 at 9:38 PM, =C2=A0<isocp...@denisbider.com> wrote:
>= ; Hey Sean,
>
> if you would like to see move destruction / rel= ocation 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 hav= e something to do with value categories. The ideal is to ensure that the co= mpiler can statically detect moved-from objects and disable destructor exec= ution and provide diagnostics when the variable is used, unless reinitializ= ed 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 impl= ement containers. How would you propose implementing

They need no su= ch thing. They use allocators. Allocators then need to use placement new (a= nd 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 cust= om containers.

> the standard library without these features?
=
You're forming strawmen. The standard library can be implemented pu= rely with compiler intrinsics for all it matters in this context.

&g= t;
> It is not the intention of this Relocator proposal to be used di= rectly 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 effi= ciency 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 de= faulted function rules, and so on. It's a ton of work to add to the sta= ndardese and a ton of work to implement for exceedinly little pay-off and l= eaves us still needing _another_ solution for the other problems that make = users (not just a handful of stdlib implementors) clamor for destructive mo= ve.

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

Nobody has y= et proven that we need to settle for a complicated half-solution. So let= 9;s not settle. :)

>
> Language users should not have to wo= rry 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 li= brary types to implement relocators and move constructors.

In which = case, we just need a new type trait and some rules in the standard containe= rs, 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 t= o hear about it.

My very rough ideas would be to study value categor= ies and rules and find the set of categories that allow for in-place object= destruction and marking an object as "expired" so that the compi= ler knows it doesn't have to invoke destructors. This also ties into li= fetimes, and possibly needs to integrate with a more nuanced notion of obje= ct lifetime in C++ (and hence possibly should be "bundled" with l= ifetime extension a la N4221)
No, that's not a complete idea. I'm not saying I have a magic solu= tion. It may well take _years_ to get any version of this right. If these t= hings were easy or obvious, C++98 would have been a perfect language that n= ever 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 featu= re requiring such extensive compiler support. If it's just for stdlib i= mplementors 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 functional= ity, (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 im= poses on implementors.

You should either make your proposal much sim= pler 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 sol= ving. What you have now is heavy-weight but only solves a very mundane prob= lem.

>
>
> On Wednesday, April 6, 2016 at 10:45:09 PM= UTC-6, Sean Middleditch wrote:
>>
>>
>> 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 i= t can do no such thing for
>> > > user types. However, the c= ommittee _does_ want to allow variant
>> > > to be used with= those same problematic user types.
>> >
>> >
&g= t;> > With respect to variant, it is already a major advantage of rel= ocation
>> > that it can support:
>> >
>> = > - exception-safe use of variant with non-nullable standard library typ= es
>> > - without requiring an existing std::list implementatio= n to be thrown away
>> > so it can be nothrow_move_constructibl= e;
>> >
>> > - exception-safe use of variant with f= uture non-nullable types.
>>
>> But not "exception s= afe" for other types, meaning that it still requires
>> the w= ork around with the valueless state. So we go from a "mostly never
= >> empty" container to a "slightly more mostly never empty&= quot; container. :)
>>
>> >
>> >
>&g= t; > Existing problematic non-library types can of course still be suppo= rted,
>> > if we're willing to lose the strong exception sa= fety guarantee in that case.
>> > I'm not sure there is a s= ilver bullet that can avoid that.
>> >
>> >
>= > > > With your proposal, it's way too easy to accidentally le= ave
>> > > some object in an undefined state
>> >= ;
>> > I find this logic highly questionable. By this line of r= easoning, we
>> > should remove placement new, C-style casts, a= nd manual memory management, so
>> > that C++ might become a ma= naged language.
>>
>> Not at all, and that's quite th= e logical jump. For one, your feature
>> doesn't actually exis= t yet, while those others do; adding unsafe features
>> and keepin= g old unsafe features (that we actually _do_ kinda-sorta
>> deprec= ate, 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 bin= ary
>> equation of assembly vs C# :) =C2=A0Rust for instance is a = case of going too far
>> with protecting users from mistakes and g= oing straight into forcing users to
>> jump through hoops to convi= nce the compiler of the validity of perfectly
>> valid code. It er= rs completely on the side of safety. Nobody is (seriously)
>> advo= cating that for C++. Neither should we be advocating to adding more
>= > C-level-dangerous constructs to C++ without darn good reason. Half-fix= ing
>> 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 open= s whole new classes of mistakes than
>> what we have today. The on= ly mechanism even close to being as dangerous is
>> delete/free an= d modern C++ all but deprecates those features in user code,
>> ev= en in high-performance situations like AAA games. A "good" destru= ctive
>> move should _reduce_ errors in existing code -- like acci= dentally using
>> moved-from values -- rather than adding new ones= .. Performance alone isn't
>> good enough. Remember, rvalue ref= erences _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= 9;m more than happy to see you work on it; you seem
>> like a pret= ty bright person and are obviously passionate about the issue. I
>>= ; just strongly think that the proposal you currently have just isn't &= quot;there"
>> yet and needs more design iteration. :)
>= ;>
>> >
>
> --
> You received this message= because you are subscribed to a topic in the
> Google Groups "I= SO C++ Standard - Future Proposals" group.
> To unsubscribe from= this topic, visit
> https://groups.google.c= om/a/isocpp.org/d/topic/std-proposals/jdY0hieE0E0/unsubscrib= e.
> To unsubscribe from this group and all its topics, send an e= mail to
> std-proposal...@isocpp.org.
> To post to this gro= up, send email to std-pr...@isocpp.org.
> To view this discussion on t= he web visit
> https://groups.google.com/= a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-a1ca-0= 3f33a9900c0%40isocpp.org.



--
Sean Middleditchhttp://seanmiddleditch= ..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/30181f63-7189-494d-9294-3f8b8759308f= %40isocpp.org.
------=_Part_151_941910145.1460095636654-- ------=_Part_150_1744017611.1460095636653-- .