220 25480 <5fa18812-ef38-49de-814c-0d062124c4d2@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: Fri, 8 Apr 2016 00:18:58 -0700 (PDT) Lines: 575 Approved: news@gmane.org Message-ID: <5fa18812-ef38-49de-814c-0d062124c4d2@isocpp.org> References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> <30181f63-7189-494d-9294-3f8b8759308f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6_378321275.1460099938908" X-Trace: ger.gmane.org 1460099945 24642 80.91.229.3 (8 Apr 2016 07:19:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 07:19:05 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBZFWTW4AKGQE4AJEGOA@isocpp.org Fri Apr 08 09:19:04 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aoQh4-0005uM-EX for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 09:19:02 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id fg3sf42205138obb.3 for ; Fri, 08 Apr 2016 00:19:02 -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=RYRi5W3542LDcmewwk59EFgPa2LEU+2/FYYeKQCURLo=; b=ugRG8TdsMaq3H9ifH7xacxsTZ6uep07UAfIu6Wnu/LYocC7iEIe1IDwtejW8ShIPyQ FGxcKsuV1Je9RvGzi77V584RSDkp1Cpu1JyzCgPeKTYufDvd36e8Oew3fD73NXr5kvu1 Btx6VXW9gMlMSp4LT76+rO/jWUG4BGBrV9m+BD5d3HiEYAVP79/yniWMH0mUG8SOXOmu 7FlRzkC8ONo1uQf9JqlNnhox5plFnq43yJkyNjFIjp+GSaZNhW98DX+PfHCCbq88vHrh nykoKj7hVyb9yI4ZSPzQCR5tJPpM3b/DocXRTnuL24fIjb4oGUn5qpxgeO9OeaPtRrJj 4XYQ== 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=RYRi5W3542LDcmewwk59EFgPa2LEU+2/FYYeKQCURLo=; b=UXGfjBCzrTcc61R4xPCDNhoUywO1KCG86OGNMxPHylmsdlmxl2WfzNOFyVbAxv5uay BLkrIjQPHYhF1WZdoyvp0va5ZrxYkUNSUepXtndouk2sH3YngybMRJIji0Q+ElHpHsOD /WTXsFHmLI57OTpLXkIzcVeymgA7kLFiM9urWR/GIVxSqMOPsUwoMcFhTIRE3zzjpO0n X0/88sSx6WqDtclgWXLN05d6ZrUVtumxSgGE1tZiVIQPyn2aFP6OK0nAgc/rVhxkX6BR pyQ7vGz+YN5iLTZMqyhjyJ9KkI5Op9E6aLmGeqwc58fAEUYbQW6BbIBwHR+t3iZW1ya2 rzCA== X-Gm-Message-State: AD7BkJJileZX1Br8JFA1QLkrUKWe0ebjIJ1OzN55wB6uPTfYwt43V+5KrYkDcuiVKO/Mjg== X-Received: by 10.107.157.10 with SMTP id g10mr5092282ioe.28.1460099941213; Fri, 08 Apr 2016 00:19:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.145.197 with SMTP id t188ls344072iod.100.gmail; Fri, 08 Apr 2016 00:19:00 -0700 (PDT) X-Received: by 10.50.88.3 with SMTP id bc3mr29769igb.6.1460099940006; Fri, 08 Apr 2016 00:19:00 -0700 (PDT) In-Reply-To: <30181f63-7189-494d-9294-3f8b8759308f@isocpp.org> 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:25480 Archived-At: ------=_Part_6_378321275.1460099938908 Content-Type: multipart/alternative; boundary="----=_Part_7_518778252.1460099938909" ------=_Part_7_518778252.1460099938909 Content-Type: text/plain; charset=UTF-8 Let me expand on this. In doing so, I hope to help you guys understand the developer audience that, in the name of "modernity", you are alienating. The key value of C++, to me, is in the following: (1) Control. There is no limit to how much control I want to have. (2) Expressiveness; including tools to exercise control safely. Notice I haven't mentioned the standard library. *I do not use the standard library.* Some 16 years ago, I found that all the standard library *actually* does is come between me and the *actual* platform. Rather than giving me control, it takes away from it. It imposes this faulty layer of abstraction; with behaviors that can change between compiler versions; with limitations that turn out to be problematic for me; with subtle design issues and bugs that I can't work around or fix. So, *sometimes* I use the standard library. More often than not, though, I rely on my own containers, which fit usage cases the standard library does not; including vector and string. And as much as possible, I work with the underlying platform *directly*. This has turned out to be a good decision. With your attempts to "modernize" C++, this is a type of audience you are alienating. With a medical analogy, the conversation we're having is like this: *Surgeon:* I propose this new scalpel, which does these things better than the old scalpel. *Committee:* Ah. Well that's good. But it is not good enough. The new scalpel is unsafe. *Surgeon:* How is it unsafe? *Committee:* The scalpel needs to make sure you're not cutting the wrong thing with it. *Surgeon:* Isn't it up to the surgeon to be sure what he's cutting? *Committee:* That's old style thinking. In new surgery, we only want *safe* tools. *Surgeon:* But the old scalpel has no such protections either. The old scalpel is just... a scalpel. *Committee:* Yes, yes. If we could do it again, we would not have allowed that. *Surgeon:* How would we even design a scalpel that knows what it's cutting? *Committee:* Well, I'm sure someone like you will come along and tell us! From my perspective - your attempts to build a better standard library are commendable, and to some extent they are even useful to me, when it improves the language. However, I worry that folks are beginning to lose sight of that the C++ standard library is *an* option; not *the only* option. C++ is more than STL. On Friday, April 8, 2016 at 12:07:17 AM UTC-6, isocp...@denisbider.com wrote: > 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/5fa18812-ef38-49de-814c-0d062124c4d2%40isocpp.org. ------=_Part_7_518778252.1460099938909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me expand on this. In doing so, I hope to help yo= u guys understand the developer audience that, in the name of "moderni= ty", you are alienating.

The key value of C++= , to me, is in the following:

(1) Control. There i= s no limit to how much control I want to have.
(2) Expressiveness= ; including tools to exercise control safely.

Noti= ce I haven't mentioned the standard library.

<= em>I do not use the standard library. Some 16 years ago, I found that = all the standard library actually does is come between me and the = actual platform. Rather than giving me control, it takes away from= it. It imposes this faulty layer of abstraction;=C2=A0with behaviors that = can change between compiler versions; with limitations that turn out to be = problematic for me;=C2=A0with subtle=C2=A0design issues and bugs that I can= 't work around or fix.

So, sometimes = I use the standard library. More often than not, though, I rely on my own c= ontainers, which fit usage cases the standard library does not;=C2=A0includ= ing vector and string.

And as=C2=A0much as possibl= e, I work with the underlying platform directly. This has turned o= ut to be a good decision.

With your attempts to &q= uot;modernize" C++, this is a type of audience you are alienating. Wit= h a medical analogy, the conversation we're having is like this:
<= div>
Surgeon: I propose this new scalpel, which does= these things better than the old scalpel.
Committee: Ah= .. Well that's good. But it is=C2=A0not good enough. The new scalpel is = unsafe.
Surgeon: How is it unsafe?
Committ= ee:=C2=A0The scalpel=C2=A0needs to make sure you're not cutting th= e wrong thing with it.
Surgeon:=C2=A0Isn't it=C2=A0u= p to the surgeon to be sure what he's cutting?
Committee:= That's old style thinking. In new surgery, we only want s= afe tools.
Surgeon: But the old scalpel has no = such=C2=A0protections either. The old scalpel is just... a scalpel.
Committee: Yes, yes. If we could do it again, we would not have= allowed that.
Surgeon: How would we even design a scalp= el that knows what it's cutting?
Committee: Wel= l, I'm sure someone like you will come along and tell us!

From my perspective - your attempts to build a better sta= ndard library are commendable, and to some extent they are even useful to m= e, when it improves the language.

However, I worry= that folks are beginning to=C2=A0lose sight of=C2=A0that the C++ standard = library is an option; not the only=C2=A0option.

C++ is more than STL.


On Friday, April 8,= 2016 at 12:07:17 AM UTC-6, isocp...@denisbider.com wrote:
Ah, Jesus.

It seems to me C++ has become infested with people=C2=A0who call themselve= s "modern", but whose=C2=A0objective is to=C2=A0desperately try t= o divorce=C2=A0the language=C2=A0from its low-level origins, while=C2=A0ash= amedly having to=C2=A0recognize 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 standar= d library monstrosity, which is=C2=A0trying to pretend that C++ can be a pl= atform. But the=C2=A0role 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= 9;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, =C2=A0<isoc= p...@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 what that safer form would look like?
Not with great specifics, or else I'd have written a paper on thi= s. :)

I'd imagine it'd have something to do with value categ= ories. 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. Wel= l,
> yes, of course. But libraries still need to use new and delete, = as well as
> placement new, to implement containers. How would you pr= opose implementing

They need no such thing. They use allocators. All= ocators then need to use placement new (and never delete) in almost all cas= es, but that is deeply separate from most user code. Very few C++ users hav= e written custom allocators. Or even custom containers.

> the sta= ndard library without these features?

You're forming strawmen. T= he 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 i= ntention 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... w= hat else? we've already gone over how it doesn't fix variant) and i= nvolves 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 impl= ement for exceedinly little pay-off and leaves us still needing _another_ s= olution for the other problems that make users (not just a handful of stdli= b implementors) clamor for destructive move.

It'd be like adding= an incomplete version of move semantics that just added a new special synt= ax for move construction without also adding rvalue references or the exten= ded value categories.

Nobody has yet proven that we need to settle f= or 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 relocator= s and move constructors.

In which case, we just need a new type trai= t and some rules in the standard containers, and _zero_ new language featur= es. 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 ro= ugh 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 i= nvoke destructors. This also ties into lifetimes, and possibly needs to int= egrate with a more nuanced notion of object lifetime in C++ (and hence poss= ibly should be "bundled" with lifetime extension a la N4221)

No, that's not a complete ide= a. 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 mistak= en for a feature that end users should
> directly use.

Then it= has no reason to be a heavy-weight feature requiring such extensive compil= er support. If it's just for stdlib implementors and stdlib types, they= can already offer relocation completely today as a point of QoI via privat= e type traits purely in library code. 100% guarantee it, as I primarily use= one that does just that.

However, it turns out that "stdlib on= ly" is not actually useful because (a) stdlib containers want to suppo= rt 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 co= mplicated problems worth the burden it imposes on implementors.

You = should either make your proposal much simpler pure-library affair or you sh= ould think bigger and try to solve a much larger set of the problems that d= estructive move / relocation could be solving. What you have now is heavy-w= eight but only solves a very mundane problem.

>
>
> O= n Wednesday, April 6, 2016 at 10:45:09 PM UTC-6, Sean Middleditch wrote:>>
>>
>> On Apr 6, 2016 9:55 AM, <isocp...@d= enisbider.com> wrote:
>> >
>> > > The com= mittee can mandate that standard library types all have
>> > &g= t; relocators added where necessary but it can do no such thing for
>= > > > user types. However, the committee _does_ want to allow vari= ant
>> > > to be used with those same problematic user types= ..
>> >
>> >
>> > With respect to varian= t, it is already a major advantage of relocation
>> > that it c= an support:
>> >
>> > - exception-safe use of varia= nt with non-nullable standard library types
>> > - without requ= iring an existing std::list implementation to be thrown away
>> &g= t; so it can be nothrow_move_constructible;
>> >
>> &g= t; - exception-safe use of variant with future non-nullable types.
>&= gt;
>> But not "exception safe" for other types, meaning= that it still requires
>> the work around with the valueless stat= e. So we go from a "mostly never
>> empty" container to = a "slightly more mostly never empty" container. :)
>>>> >
>> >
>> > Existing problematic non-l= ibrary types can of course still be supported,
>> > if we'r= e willing to lose the strong exception safety guarantee in that case.
&g= t;> > I'm not sure there is a silver bullet that can avoid that.<= br>>> >
>> >
>> > > With your proposal,= it's way too easy to accidentally leave
>> > > some obj= ect in an undefined state
>> >
>> > I find this log= ic highly questionable. By this line of reasoning, we
>> > shou= ld 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 feat= ure
>> doesn't actually exist yet, while those others do; addi= ng unsafe features
>> and keeping old unsafe features (that we act= ually _do_ kinda-sorta
>> deprecate, e.g. the modern advice to nev= er ever use new/delete or C-style
>> casts) for back-compat are tw= o very different things. :)
>>
>> For two, there are degr= ees of ease-of- misuse and not just a binary
>> equation of assemb= ly vs C# :) =C2=A0Rust for instance is a case of going too far
>> = with protecting users from mistakes and going straight into forcing users t= o
>> jump through hoops to convince the compiler of the validity o= f perfectly
>> valid code. It errs completely on the side of safet= y. Nobody is (seriously)
>> advocating that for C++. Neither shoul= d we be advocating to adding more
>> C-level-dangerous constructs = to C++ without darn good reason. Half-fixing
>> variant and not ac= tually 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).
>>
>&= gt; For three, your feature proposal opens whole new classes of mistakes th= an
>> what we have today. The only mechanism even close to being a= s dangerous is
>> delete/free and modern C++ all but deprecates th= ose features in user code,
>> even in high-performance situations = like AAA games. A "good" destructive
>> move should _red= uce_ errors in existing code -- like accidentally using
>> moved-f= rom values -- rather than adding new ones. Performance alone isn't
&= gt;> good enough. Remember, rvalue references _real_ goal was to allow u= s to
>> replace things like the easy-to-misuse auto_ptr with the m= uch superior
>> unique_ptr. The potential performance improvements= of move semantics were
>> icing on the cake.
>>
>&= gt; Now let's be clear: the intent of relocation is good. We need someo= ne
>> working on this, IMO. I'm more than happy to see you wor= k on it; you seem
>> like a pretty bright person and are obviously= passionate about the issue. I
>> just strongly think that the pro= posal you currently have just isn't "there"
>> yet a= nd needs more design iteration. :)
>>
>> >
>
= > --
> You received this message because you are subscribed to a t= opic 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-<= wbr>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 disc= ussion on the web visit
> https://groups.= google.com/a/isocpp.org/d/msgid/std-proposals/4f31b957-05be-47cf-= a1ca-03f33a9900c0%40isocpp.org.



--
Sean Mi= ddleditch
http://sean= middleditch.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/5fa18812-ef38-49de-814c-0d062124c4d2= %40isocpp.org.
------=_Part_7_518778252.1460099938909-- ------=_Part_6_378321275.1460099938908-- .