220 38017 article Path: news.gmane.org!.POSTED!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: variant again Date: Wed, 25 Apr 2018 21:44:35 -0500 Lines: 256 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c1925c0a4cbeb056ab760c7" X-Trace: blaine.gmane.org 1524710592 19220 195.159.176.226 (26 Apr 2018 02:43:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2018 02:43:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCE35H5S6IDBBPP2QTLQKGQEDDZ3V3A@isocpp.org Thu Apr 26 04:43:08 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fBWsF-0004tG-QR for gclcip-std-proposals@m.gmane.org; Thu, 26 Apr 2018 04:43:08 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id g6sf20030970uak.2 for ; Wed, 25 Apr 2018 19:45:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1524710718; cv=pass; d=google.com; s=arc-20160816; b=Hf94aRXd9lpo1gPYfdyacMDLQGLCuZ3fugQ+oYpqkaksdP0zuQPMsgZZ287IVgs5aR wU9+CY4crB4YY5p1zjb/mdTDf1lcamp6E7pZJFyuElSd9ZqNyMhkVc/Z/92Q9cF9pS8e tkw0spdcBVQvMT2hz2aYmv+fYX1tUT1th6A2RyX0oRVKfqNj1mEjb5i8ZE6vbv+lvPsh JzxNgZUE9g5ov/YktH6C63CJJiPgwfUwcMhakLS7PF8/22sjFn3QciUiyy2apulO/XTG XiI6oDTJDpY39zoqd97AqUKN969AEl9EdLv3pDr3+YeMHGdemOxVYCOpo+tKy/xYzJ5x 6qWQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:sender:mime-version :arc-authentication-results:arc-message-signature :arc-authentication-results; bh=ozAILGd07LqYsTmqNZQs8UyNGnDrV7L1QX9vFWmhiqs=; b=QfIUllkFswn6RhVRfISaS9GPpRCMJD/ri5ZePO5oTBp6mVD6zPG5tbGziN4zZz/yM3 l5BP6hIdsJJoiafYJrIuFwMrXuxZTKYYF5VPT6vUw4yzV4pMMjaHwYFrkXhJkg2zMBcb pwhBRQ0g3u27qgWtZeySBUhtONN61gGNbAO/t3m6FzjTcwvXPWyeo0UFa6TumwxZvJpf YwNZZxTNcbFol1ksjWiYwKwx+m0dJBrxdbVbvKEHt6Oi0FLCghRCTp+7q2tF4rP7iwqw Vi0hyBW7WgWG+uw0Yt3UH/OcFmIMN6JdmFuoVvYACaT4CnmCJuvi4HnlrIBWPDQ+KY/5 JUow== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OxNR8xPl; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=nliber@gmail.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject: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=ozAILGd07LqYsTmqNZQs8UyNGnDrV7L1QX9vFWmhiqs=; b=F/KVEdrcWBlCpdHrA13gN/pYHGs8x3yqr/2UmeQGCAie70Oih8hGFDrQ2u3aScMg22 ZvDhP08THyVSniQa5w51LCdLT2tRDnUZKsbHNDZjlnTcd79Ol1NL2PP7bcIywXmYZXfG VeM0usQ5CnvZcxTkpJyEyNylG+jaVUlGQoSgc4IsKRtGG9Ttrnwm+wBFLxJvR6DfCNz8 8fwWp+dVAZ7Hek5Syp7LrdCeGLKQF1fLzMJx383ehT9RrlYuICE4u5Jmj8Sy7+NHW5Dg pHGsuTvCPX2CzoD5DuhKC0yzlYVyETzoULuaLiQFkIDnZhtRxPwakvLkZsd0INgyjTmD QMrg== X-Gm-Message-State: ALQs6tA6sZrx+oC5U/Xc2BHsbNgjhAi4DKUql9pjTFRSakghQy4kzqlA ImGvKXa1j4OCgAy1zS/s0rA= X-Google-Smtp-Source: AIpwx4/IEMbMjb7W2xOVPe5yk2FnMWMchx2lHPm0VTOO9c8iDc3Hr2v+oCt1AfabzXJ3DFSX4l/G8A== X-Received: by 10.176.90.41 with SMTP id l38mr14373794uad.13.1524710718334; Wed, 25 Apr 2018 19:45:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.180.202 with SMTP id d193ls11776001vkf.6.gmail; Wed, 25 Apr 2018 19:45:17 -0700 (PDT) X-Received: by 10.31.171.9 with SMTP id u9mr22468562vke.81.1524710717267; Wed, 25 Apr 2018 19:45:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524710717; cv=none; d=google.com; s=arc-20160816; b=t0XHlmybhltglPWNeYLVF3m0hByRgx7qtsTfeqpKAzGFZ64xTjgdth7z5LgtYOwd6D vkWKRKLY3tHnyqU/ewaItetN8nx+bqXSrWW7LeXB4uQ77IzJY/hNJSTgNxOoYg3m9N/h GJI1pVxl9bhqLJyYZav5jQqGOwWhIaRePY/292WexCfPJGjvlWYZLwJUQCbRtkzFM0Il ySln3O+G72JQNGfR2ysnPdyt9jupN1fp5Zid/jT7WGJqLKhqy5gF1vxpAS3QA7vZ8ABp O9BeRHRsybkPGUEQfD54fVSgO/EOIbueL08uYvG037x9/byNKEwGNwLYgiZD3TgGyhMw m4RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:dkim-signature:arc-authentication-results; bh=pWzhCHQhnkENvD994yG89qkdW9V+lxlJNhWMOuVQRS4=; b=sAx+oZjUCddxNHkB7cspax/+Ra5gseKXX3RWUOFTG5tle+JtrUWJ3WbtdG9T8sfJ8A P4ngnnUgCNrwaYVRzJwANr3nOZKEdm3bnBAxDmxa25KFoWvJjjnUk8tXvRbn69OPwAnu 0k9Q+juS0SlXfEnJT9VOKzDoOfluvoeOFudIqFQoz+GwvgmMozKP9m/gNe1aSDBcsG4J kxjBjw6eOKPyv6X6lpVPHxJAabOontNiFbXBdYIh7ID3Drld/7DpT4mi9GyDC4+/zEVo rqeh81myaPN2ggA3BYvTo6EkCqx3UT53jVoE1MhY+94y1dtijDG99Pzk6vOP71b7s+Kw edfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OxNR8xPl; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=nliber@gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 9sor7755481uas.168.2018.04.25.19.45.17 for (Google Transport Security); Wed, 25 Apr 2018 19:45:17 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.176.80.213 with SMTP id d21mr23309825uaa.86.1524710716523; Wed, 25 Apr 2018 19:45:16 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.103.118.200 with HTTP; Wed, 25 Apr 2018 19:44:35 -0700 (PDT) In-Reply-To: X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OxNR8xPl; spf=pass (google.com: domain of nliber@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=nliber@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:38017 Archived-At: --94eb2c1925c0a4cbeb056ab760c7 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018 at 5:47 PM, 'Matt Calabrese' via ISO C++ Standard - Future Proposals wrote: > > > On Wed, Apr 25, 2018, 18:00 Nevin Liber wrote: > >> On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO C++ Standard - >> Future Proposals wrote: >> >>> Then would you or would you not be in favor of a proposal to require >>> that we do not enter the valueless_by_exception state here? Tony's concern >>> is that the current specification implies that we can get to >>> valueless_by_exception in an assignment even when a move constructor does >>> not actually throw, which is currently true. Should we "fix" this in a >>> future standard or consider to be fine? >>> >> >> I would be against because we have better things to do with committee >> time. >> >> Variations on Boost.Variant, which IIRC picks the first no-throw >> default-constructible type on the type list. were already discussed and >> rejected. >> > > I'll restate: I'm pretty sure you are misunderstanding the specific case > we are talking about. Forget about Boost.Variant or a lack of valueless by > exception -- that ship sailed and this has little to do with it. I am not > at all saying we should try to change consensus on something that already > shipped. Look again at the example -- we are getting to the valueless by > exception state from an assignment operation without ever even having a > move operation that throws, which many advocates of valueless by exception > did not want. We certainly can avoid this if the committee decided (this is > in line with expressed intent and we've already made other changes to > minimize valueless by exception). > As Tony said: Why doesn't variant revert back to the int when the copy throws? We don't > want to pay for the moves? No, I don't want to pay for the moves. Moves aren't free, and at times they aren't even cheap. Maybe I'm misinterpreting the above, but the way being proposed to avoid valueless_by_exception is by introducing an extra move operation to temporarily double buffer, *which is a performance pessimization on the far more common case of not throwing*. Oh, and that move operation may *terminate*, because noexcept only guarantees that an exception will not escape the function call. The people I have worked with have consistently wanted variant to be as fast as possible in the non-exception case. When the choice was between not having variant in the standard and having a variant that may not be as fast as possible, I chose the former, because having variant in the standard was strictly better than not having it. Consensus isn't about getting what you want; it's about getting what you can live with. Now that it shipped with C++17, I no longer have to make performance compromises with regards to variant. And I certainly don't want to tell users that if they want their variants to perform better, they should mark their operations as noexcept(false) so as not to trigger the pessimization. And we already spent a huge amount of committee time debating these issues. There is nothing new here. Reopening debate just because either the grass is greener on the other side, or people didn't quite get their way the first n times we debated it isn't productive. Without new information being presented, I don't see the point. > I agree that particular aspect hasn't changed. I'm also not sure you > realize that I am speaking for those who I disagree with -- members who > advocated for valueless by exception explicitly want to minimize getting > into the valueless by exception state. If we don't care to make further > changes then that is fine, but I do not understand the backlash. We've > already made changes akin to this during standardization "with no new > information". Let's at least figure out what the committee's actual goal is > here. > The committee (and not just one of the WGs) debated variant in an evening session and came to consensus, which we shipped. We are back to what individual members, and not the committee as a whole, wants. > It seems that no matter which side I speak for on this topic I'm either > explicitly called insane or get pounced on. It's getting ridiculous and is > not indicative of an environment where people can speak their mind. > I have no power to stop you. Really. If you or Tony wish to make a proposal, I cannot stop you. If you two wish to try and schedule a Make Variant Great Again session in Rapperswil, I cannot stop you. All I can try and do is persuade you not to. But make no mistake: spending committee time re-debating is committee time we aren't spending on something more positive. For instance, in JAX we had to spend nearly a day debating making the built-in signed integer types always wrap, and by doing so we didn't get to any papers that might have added new operations and/or types that wrap. Was it necessary? Yes, because by our rules we had to debate it. Was it a good use of our time? IMO, no, both because it was extremely unlikely that wrapping the built in signed types would pass (it didn't) and now we don't have any progress on adding ops/types that wrap. -- Nevin ":-)" Liber +1-847-691-1404 -- 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/CAGg_6%2BM5D0myUuEqeyQ0nSgGYE_wzewBAOjUQQGsXu0s_gHCxg%40mail.gmail.com. --94eb2c1925c0a4cbeb056ab760c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 25, 2018 at 5:47 PM, 'Matt Calabrese' = via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org> wrote:


On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO C++ = Standard - Future Proposals <std-prop= osals@isocpp.org> wrote:
Then wou= ld you or would you not be in favor of a proposal to require that we do not= enter the valueless_by_exception state here? Tony's concern is that th= e current specification implies that we can get to valueless_by_exception i= n an assignment even when a move constructor does not actually throw, which= is currently true. Should we "fix" this in a future standard or = consider to be fine?

I would be against because we have better things to do with committee time= ..

Variations on Boost.Variant, which IIRC picks th= e first no-throw default-constructible type on the type list. were already = discussed and rejected.

I'll restate: I'm= pretty sure you are misunderstanding the specific case we are talking abou= t. Forget about Boost.Variant or a lack of valueless by exception -- that s= hip sailed and this has little to do with it. I am not at all saying we sho= uld try to change consensus on something that already shipped. Look again a= t the example -- we are getting to the valueless by exception state from an= assignment operation without ever even having a move operation that throws= , which many advocates of valueless by exception did not want. We certainly= can avoid this if the committee decided (this is in line with expressed in= tent and we've already made other changes to minimize valueless by exce= ption).

As Tony said:

= Why doesn't=C2=A0variant=C2=A0revert back to the int when the copy throws?=C2=A0 We don't = want to pay for the moves?=C2=A0

No,= I don't want to pay for the moves.=C2=A0 Moves aren't free, and at= times they aren't even cheap.

Maybe I'm m= isinterpreting the above, but the way being proposed to avoid valueless_by_= exception is by introducing an extra move operation to temporarily double b= uffer, which is a performance pessimization on the far more common case = of not throwing.=C2=A0 Oh, and that move operation may terminate= , because noexcept only guarantees that an exception will not escape the fu= nction call.


The people I have work= ed with have consistently wanted variant to be as fast as possible in the n= on-exception case.

When the choice was between not= having variant in the standard and having a variant that may not be as fas= t as possible, I chose the former, because having variant in the standard w= as strictly better than not having it.=C2=A0 Consensus isn't about gett= ing what you want; it's about getting what you can live with.

Now that it shipped with C++17, I no longer have to make pe= rformance compromises with regards to variant.=C2=A0 And I certainly don= 9;t want to tell users that if they want their variants to perform better, = they should mark their operations as noexcept(false) so as not to trigger t= he pessimization.

And we already spent a huge amou= nt of committee time debating these issues.=C2=A0 There is nothing new here= ..=C2=A0 Reopening debate just because either the grass is greener on the ot= her side, or people didn't quite get their way the first n times we deb= ated it isn't productive.=C2=A0 Without new information being presented= , I don't see the point.
=C2=A0
I agree that particular aspect hasn't chan= ged. I'm also not sure you realize that I am speaking for those who I d= isagree with -- members who advocated for valueless by exception explicitly= want to minimize getting into the valueless by exception state. If we don&= #39;t care to make further changes then that is fine, but I do not understa= nd the backlash. We've already made changes akin to this during standar= dization "with no new information". Let's at least figure out= what the committee's actual goal is here.

The committee (and not just one of the WGs) debated variant= in an evening session and came to consensus, which we shipped.=C2=A0 We ar= e back to what individual members, and not the committee as a whole, wants.=
=C2=A0
It seems that no matter which side I speak for on this topic I'm eithe= r explicitly called insane or get pounced on. It's getting ridiculous a= nd is not indicative of an environment where people can speak their mind.

I have no power to stop you.= =C2=A0 Really.=C2=A0 If you or Tony wish to make a proposal, I cannot stop = you.=C2=A0 If you two wish to try and schedule a Make Variant Great Again s= ession in Rapperswil, I cannot stop you.=C2=A0 All I can try and do is pers= uade you not to.

But make no mistake: =C2=A0spendi= ng committee time re-debating is committee time we aren't spending on s= omething more positive.

For instance, in JAX we ha= d to spend nearly a day debating making the built-in signed integer types a= lways wrap, and by doing so we didn't get to any papers that might have= added new operations and/or types that wrap.=C2=A0 Was it necessary?=C2=A0= Yes, because by our rules we had to debate it.=C2=A0 Was it a good use of = our time?=C2=A0 IMO, no, both because it was extremely unlikely that wrappi= ng the built in signed types would pass (it didn't) and now we don'= t have any progress on adding ops/types that wrap.
--=C2=A0
=C2=A0Nevin ":-)" Liber=C2= =A0 <mailto:= nevin@eviloverlord.com> =C2=A0+1-847-691-1404
=

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM5D0my= UuEqeyQ0nSgGYE_wzewBAOjUQQGsXu0s_gHCxg%40mail.gmail.com.
--94eb2c1925c0a4cbeb056ab760c7-- .