220 25485 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 13:25:37 -0700 (PDT) Lines: 341 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> <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_954_388927962.1460147137852" X-Trace: ger.gmane.org 1460147143 25069 80.91.229.3 (8 Apr 2016 20:25:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 20:25:43 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD5LNK7YQYJRBQ5HUC4AKGQEDLERCUA@isocpp.org Fri Apr 08 22:25:42 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f72.google.com ([209.85.192.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aocyL-0006Rc-2k for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 22:25:41 +0200 Original-Received: by mail-qg0-f72.google.com with SMTP id t38sf126955879qge.3 for ; Fri, 08 Apr 2016 13:25:40 -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=QroDEskRMYYxoXKWBPRt6P1iW7rRwziByWnpbpt6hSk=; b=Bp945MCX5c1rlijhdJfqWk4ydQI53eu/xpisFqFE+IaiyQ0Pjrj1J7tRod3y2GKqmC THGOaM1OiNBr9GCe/CyWx7VoIw6r/QkOEF5/Giho0Ar1V3lDSkxQvpHEIRpzOwdPgQUB ovRPvh0ppUk+s1d9VnGxOSytP2v1XhTSMFGE1gw3oxv0GlVpRAZROf1OeKDI4gmapjxT Ogg/gN1JiIAzny5WYTY6CoEIyhPK9N/lDhg+DKcnH5annh0SHs6C1LotIyn4/3+/8M67 /5LaG7FDTydlTWslljgXiLn7+8pRJdqiwrgRh1Byk2LtFupHrv22cY+Y2aKZvmNnFHq5 GryQ== 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=QroDEskRMYYxoXKWBPRt6P1iW7rRwziByWnpbpt6hSk=; b=Z11Gb6euXIIrfpdJTC6kJXWEwfObVWPzQon18q/PqYcGEJ7vLYiTSoBy1XAYPTi3mG PFrA1WW41Hb0atK4eMqZgf7x2LD+BndJZkWZWxCQWjwxOSsIOLL31LEaHmahKccIu7Va eFvRgSus5DCvhEq3Ke5TQWN3iL2MPwzQGi6olE8uEohicFqNEijoMKv9QoRxDm+eQvtN ALCF3FfObFq1673+U0P3nVsb0pcqHZQlWRxnTQiSRpYQmaZLSqNJsxkuVXmZ6JBRlLoY xj6mwon5hG6/gSVmb9eAtODypRtDc2NPQcijOBeOxXTUGqRUgsGl2bVH5o+mw8FwZONa Jjqg== X-Gm-Message-State: AD7BkJKy445jxab9nWb9+OqjdLOyewM/49NJNMcDE0cmGjU6qdl7ogRidYr9vCCow8BO1g== X-Received: by 10.129.72.68 with SMTP id v65mr6819600ywa.52.1460147140123; Fri, 08 Apr 2016 13:25:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.132 with SMTP id w4ls318814igl.32.canary; Fri, 08 Apr 2016 13:25:38 -0700 (PDT) X-Received: by 10.50.43.234 with SMTP id z10mr139647igl.4.1460147138824; Fri, 08 Apr 2016 13:25:38 -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:25485 Archived-At: ------=_Part_954_388927962.1460147137852 Content-Type: multipart/alternative; boundary="----=_Part_955_1309426839.1460147137853" ------=_Part_955_1309426839.1460147137853 Content-Type: text/plain; charset=UTF-8 Nicol - the content of your response is no less ego-based than you claim mine is. You are deeply annoyed both by me as a person, and by what I am trying to do. As far as I can tell, this annoyance seems to be based on misunderstandings. Perhaps like this: > If your relocation support can't even perform relocation in this most simple of cases: How does it *not* handle that case? If std::list has a relocator, the compiler can just call the relocator in this case: std::list SomeFunc() { std::list lt = ... ... return lt; // no special syntax needed; compiler calls relocator >>list } What prevents the compiler from doing this? On Friday, April 8, 2016 at 8:12:03 AM UTC-6, Nicol Bolas wrote: > On Friday, April 8, 2016 at 2:07:17 AM UTC-4, 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. >> > > ... So Sean points out how move support introduced a plethora of new value > categories in order to ensure that it does not get automatically used in > the wrong place. To make sure that it's reasonably safe and usable for most > programmers. And he suggests that you should investigate this sort of thing > as a way to make sure that your "relocation" is also reasonably safe, that > it gets used automatically where appropriate, and that it doesn't get used > in improper places. And so forth. > > And your response to this is to claim that such commentary comes from > people who are "infesting" the > language, that even that we make the language *as safe as it currently is* > represents an attempt to "make this a managed language", and so forth. > You're basically saying that your design is perfect as is, and anyone who > questions it in the name of safety is "desperately try[ing] to divorce the > language from its low-level origins." > > Seriously, are you *five-years old*? > > And let's not forget the implied insult to the standards committee that > their design for move support is wrong because it actually includes such > safety features. > > Personally, my basic criticism of your proposal is that it's not even > really half of a proposal. You can only "relocate" objects who's lifetimes > are governed by `new/delete` or placement new/explicit destructor calls. > That is, not automatic objects. You're basically taking the *easy part* > of destructive move/relocation, and then pretending that you have a > complete "relocation" feature. > > If your relocation support can't even perform relocation in this most > simple of cases: > > std::list SomeFunc() > { > std::list lt = ... > ... > return lt; //Insert syntax for relocation-returning, if needed > } > > Then *what good is it*? > > In fact, there is *no way* in your proposal to relocate an object into a > return value. Not even with P0135's guaranteed elision mechanics. Since you > can only relocate an object through the use of `new`, and return values > aren't created by `new`, there is no way to use relocation on simple return > values. > > So again, *what good is this?* > > That's where the "safety" argument that Sean is making comes from. Your > proposal only works with features that are inherently unsafe and that > programmers increasingly do not use with any particular frequency. Unlike > `move`, which works on *all object*s, automatic and non-automatic alike. > > That's the basic point that Sean is (or seems to be) making about your > proposal. You cannot use your proposal without calling upon deep-magic > levels of C++, like placement new and so forth. Your features is brittle, > incomplete, and painful to use. > > Allow me to restate your asinine "scalpel" analogy/conversation to better > explain this: > > Surgeon: I propose this new scalpel, which does these things better than >> the old scalpel. >> Committee: But it doesn't do things better than the old scalpel. It >> doesn't even work most of the time. >> Surgeon: Sure it does. See, it works just fine if you stand on your head, >> and it does things even better than the old one. >> Committee: But... most people stopped performing surgery while standing >> on their head years ago. >> Surgeon: Isn't it up to the surgeon to decide how he wants to perform >> surgery? >> Committee: That's old style thinking. In modern surgery, we want tools >> that work with how we actually operate on people, not tools that force us >> to operate in a specific way. Especially ones known to be bad. >> Surgeon: But the old scalpel has no such protections either. The old >> scalpel is just... a scalpel. >> Committee: That's not true at all. The old scalpel works just fine when >> standing normally. >> Surgeon: How would we even design a scalpel that does what this does >> without having to stand on your head? >> Committee: Put some effort into it, rather than doing the bare minimum >> that you feel you can get away with. Make a *complete* scalpel. >> > > In this analogy, "stand on your head" mean "using new/delete or placement > new and explicit destructor calls". > > Indeed, it's not clear to me why it is that your proposal needs to be a > language feature at all. N4034 was able to do what you're talking about > purely as a standard library thing. All it would need to do is say that the > function ends the lifetime of the source object, and that the source object > must not be an automatic object. > > You can even have implicitly generated versions which will simply perform > a move from the source to the destination, followed by a destructor call on > the source. It would be deleted for any type `T` who's move constructor is > not `noexcept`. > -- 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/cad96977-d5d4-4eea-8169-ae1ceb8b6477%40isocpp.org. ------=_Part_955_1309426839.1460147137853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nicol -=C2=A0the content of your response is no less = ego-based than you claim mine is. You are deeply annoyed both by me as a pe= rson, and by what I am trying to do.

As far as I c= an tell, this annoyance seems to be based on misunderstandings. Perhaps=C2= =A0like this:


> If your relocati= on support can't even perform relocation in this most simple of cases:<= br>

How does it not handle that case? If = std::list has a relocator, the compiler can just call the relocator in this= case:

  std::l=
ist<T> SomeFunc()=
 {
    std::list<T> lt =3D ...
    ...
    return lt; // no special syntax needed; compiler calls relocator &=
gt;>list<T>
  }

What prevents the compiler from doin= g this?



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

It seems to me C++ has become infeste= d with people=C2=A0who call themselves "modern", but whose=C2=A0o= bjective is to=C2=A0desperately try to divorce=C2=A0the language=C2=A0from = its low-level origins, while=C2=A0ashamedly having to=C2=A0recognize that t= his 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=C2=A0t= rying to pretend that C++ can be a platform. But the=C2=A0role of C++ is no= t 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 m= ake this a managed language, for god's sake.

... So Sean points out how move support introduced a plethora of new= value categories in order to ensure that it does not get automatically use= d in the wrong place. To make sure that it's reasonably safe and usable= for most programmers. And he suggests that you should investigate this sor= t of thing as a way to make sure that your "relocation" is also r= easonably safe, that it gets used automatically where appropriate, and that= it doesn't get used in improper places. And so forth.

And your = response to this is to claim that such commenta= ry comes from people who are "infesting" the language, that e= ven that we make the language as safe as it currently is represents = an attempt to "make this a managed language", and so forth. You&#= 39;re basically saying that your design is perfect as is, and anyone who qu= estions it in the name of safety is "desperately try[ing] to divorce= =C2=A0the language=C2=A0from its low-level origins."

Seriously,= are you five-years old?

And let's not forget the implied= insult to the standards committee that their design for move support is wr= ong because it actually includes such safety features.

Personally, m= y basic criticism of your proposal is that it's not even really half of= a proposal. You can only "relocate" objects who's lifetimes = are governed by `new/delete` or placement new/explicit destructor calls. Th= at is, not automatic objects. You're basically taking the easy part<= /i> of destructive move/relocation, and then pretending that you have a com= plete "relocation" feature.

If your relocation support can= 't even perform relocation in this most simple of cases:

std::list<T> = SomeFunc()
{
=C2=A0 std::list<T> lt =3D ...
=C2=A0 ...
=C2=A0 = return lt; //Insert syntax for relocation-returning, if needed
}

Then what good is it?

In f= act, there is no way in your proposal to relocate an object into a r= eturn value. Not even with P0135's guaranteed elision mechanics. Since = you can only relocate an object through the use of `new`, and return values= aren't created by `new`, there is no way to use relocation on simple r= eturn values.

So again, what good is this?

That's = where the "safety" argument that Sean is making comes from. Your = proposal only works with features that are inherently unsafe and that progr= ammers increasingly do not use with any particular frequency. Unlike `move`= , which works on all objects, automatic and non-automatic alike.
=
That's the basic point that Sean is (or seems to be) making about y= our proposal. You cannot use your proposal without calling upon deep-magic = levels of C++, like placement new and so forth. Your features is brittle, i= ncomplete, and painful to use.

Allow me to restate your asinine &quo= t;scalpel" analogy/conversation to better explain this:

Surgeon: I propose this new scalpel, which does these= things better than the old scalpel.
Committee: But it doesn't do th= ings better than the old scalpel. It doesn't even work most of the time= ..
Surgeon: Sure it does. See, it works just fine if you stand on your he= ad, and it does things even better than the old one.
Committee: But... m= ost people stopped performing surgery while standing on their head years ag= o.
Surgeon: Isn't it up to the surgeon to decide how he wants to per= form surgery?
Committee: That's old style thinking. In modern surger= y, we want tools that work with how we actually operate on people, not tool= s that force us to operate in a specific way. Especially ones known to be b= ad.
Surgeon: But the old scalpel has no such protections either. The old= scalpel is just... a scalpel.
Committee: That's not true at all. Th= e old scalpel works just fine when standing normally.
Surgeon: How would= we even design a scalpel that does what this does without having to stand = on your head?
Committee: Put some effort into it, rather than doing the = bare minimum that you feel you can get away with. Make a complete sc= alpel.

In this analogy, "stand on your head&q= uot; mean "using new/delete or placement new and explicit destructor c= alls".

Indeed, it's not clear to me why it is that your pro= posal needs to be a=20 language feature at all. N4034 was able to do what you're talking about= =20 purely as a standard library thing. All it would need to do is say that=20 the function ends the lifetime of the source object, and that the source object must not be an automatic object.

You can even have implicitl= y generated versions which will simply perform a move from the source to th= e destination, followed by a destructor call on the source. It would be del= eted for any type `T` who's move constructor is not `noexcept`.

--
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/cad96977-d5d4-4eea-8169-ae1ceb8b6477= %40isocpp.org.
------=_Part_955_1309426839.1460147137853-- ------=_Part_954_388927962.1460147137852-- .