220 38020 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: variant again Date: Thu, 26 Apr 2018 14:32:36 +0000 Lines: 428 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="000000000000e66d50056ac14209" X-Trace: blaine.gmane.org 1524753043 15278 195.159.176.226 (26 Apr 2018 14:30:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2018 14:30:43 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBEGGQ7LQKGQEZ3MM74I@isocpp.org Thu Apr 26 16:30:39 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fBhux-0003s6-2d for gclcip-std-proposals@m.gmane.org; Thu, 26 Apr 2018 16:30:39 +0200 Original-Received: by mail-io0-f200.google.com with SMTP id s12-v6sf2770838ioc.20 for ; Thu, 26 Apr 2018 07:32:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1524753169; cv=pass; d=google.com; s=arc-20160816; b=ObOlwuqb5j7HW1xlBV9kPg6pAps8i6gh8HPETj77MNGRLGABu/i8zbFNPKzcRste9h v4sC+kY1dpa5azSdgi1l3j8lrBUXczHCUFppZ4JK21/iBiJxS+tOKY6Oi7afkvLWQ0SG MKuqIzLJmpLwHHxY8c0HM/0vYiMxfUHth8BN3ocFi3va8e6vBzj0FiF9TAxMDJtnJRxw HKJtgSyMyaWtGGEO4CiXWM5hP7gazAqTjSeDdgV49xYMLm5DtuFY2HI/U4/LNj0MsUFA xJRjUD/uVpxO4Juk0fzWJ9uJrHh1vAh/MOVcvbT0ile9XBmSbNR9VnCH7Bfk9E7mi2Fh B9Rg== 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:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=KifWjlrd36jZefLafzc+QNJj65+/iQRtIikaKr2vHcM=; b=jeyRJnZWFweys/1GICAg6CqahfLPKZYpgiRzpOBZmGMASeEyGPSC+Yj2FMOghj+O2L 7/fwe4FrDNt7sruxaKn3ndWq6BxL8UAA1/Hop1weOtErVzhQZ9oOqh1CLLl55tCTF+xY 6kqkP6Fc5pIo6klXeevMvms2U00YnXaXmg4hIxGrNx7lkpKJDid21fwkqmhVKO5Ts6xE 8+LGcNnOZ8sd8h7im620vZvJOt6F3DVOdtkY0dQZ5hpgUy3LGh8esIrNTgE3xUCpNCRk GMx+btx46eqkicTqJ3R1ceC0TjUAfnqQVgW+iJ8QekK9hix2syQT02UbrtjfMsiXgvS/ W2zQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iOU9fyL4; spf=pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KifWjlrd36jZefLafzc+QNJj65+/iQRtIikaKr2vHcM=; b=UVXO+bvIcGJfo3F0KEpbx+xIuboIjxOWkMJn8sfmniwsH08DRVIL1fv5MbXVa3pTOJ Kagj5Pb7zNFlMVgjrxD/+k//6hb4IltNZLhnSgrRGCdSwL99b9Im1SOph4f5aHveYByO UDBO3ZIf0lvE4AyvwXIfT7PudOrWAx3231HAEyZGk4qtsPMSD7QcnlVu4fO9GP9uzaoi jDlDNIvXClaXwenkYwzJ3H/9VpYibrKlW021U9Qz28k4Q82fV02TP+sYa1CUI48ouxGq 445iLBErRiDv9LE7pwXP0TCk+260pWqk06BOUhpyH93CR9++7PQhqQOMEOdP4OyrcRLa XK6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=KifWjlrd36jZefLafzc+QNJj65+/iQRtIikaKr2vHcM=; b=GQZUfAC4YC8KMo/m5JqLWoZ4Kp9iMRGVsDDxu3EiCA/KpvQT1PJMbvIIYGl9wlYL/f hb/6xs9lyBqwD47fFatX+pRVqDxXEw/OxjBThQhv+rW6K6bSTlMsZowPTg8WtMFk5SKb SfECwJ/vaM0Vt9JKjZ0EjmFfBrjBehIEEv2a6zHRhkFDoxRvIKv2sF6u6OtphKQ3fi7/ nCJfqwAL61aRRHbfw5GSgVPwLgD27jMt73wFrmue8RvJJvVImbKMgHim+quaZcTRuTRG XSSsgLpJD8oOMEDoEWkb4t+7UTmhgrZ4d+htd9f0sF+JO9BqM9J0fQAUiTbC+gdvKAAk jNBw== X-Gm-Message-State: ALQs6tDlkUAzsUguxLAgAzI/vo+0GyOxq3hk2Yk+fIpRk5bR6CWRYKN2 BYB1Wggz8blOA/XpWuItKl8= X-Google-Smtp-Source: AB8JxZr+My4fXHk//E+o7csa0pz2D89maYUNmHx2br4GRo2xoXW6oCcdab+JNCQ4izNQagkxT9uNog== X-Received: by 2002:a6b:a24c:: with SMTP id l73-v6mr10768412ioe.29.1524753169572; Thu, 26 Apr 2018 07:32:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a6b:f206:: with SMTP id q6-v6ls4686934ioh.21.gmail; Thu, 26 Apr 2018 07:32:48 -0700 (PDT) X-Received: by 2002:a6b:dd16:: with SMTP id f22-v6mr25763745ioc.7.1524753168379; Thu, 26 Apr 2018 07:32:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524753168; cv=none; d=google.com; s=arc-20160816; b=xtavlcDXtgRtcCV5HkCsqSmni9C3iHUbsMmM1SDoFweTtNx/CKaYGKdgnWu1D6K2bj IgyzF5PhU66QAbznvJkm8j6xj737VDUdhZnJuGvFsFs2tgiLPVIqP6Xnd1pXZJqvgjsP cP8ix/WApHp0xx2FMZsl5ZGrCr9Hvtvy6vnaFhCzkhHJZPTdh0dmz19OeIchoDs6Gjih ztfDHI44vPUO2pE9fEHBG2ne4baiT5blXt3gSxkUMnfgxIAjslQCQm3PlVBTdJqhWrk6 dwNv/U82ZCebWtLwhSrRPBtry7IhHqaBkMLqPnK8VpoJqOSakcQCNSHy0R5eoz7Coo1L EhPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=E5V/GY7lO0m0m7DxoMqpVeS5kCpgjpWi+XyXucTR4+8=; b=dUVo3LGscPXbvKOl/vJZmyNo9hESfRR1tIQ2WzXTvZS9i1M60VoXlzcs9lZbrZIDeW 19kALYqjVSPNBgdb+QhaU1UE6WsYy8xaQ6kp8LZmk4NAisI46PgyEZdWA9FWsg4C/wwH 2AtUHqTliiBnLf5xvJeJliZr1xMyzQISHFtW5zR7QdUlCWAGHvdlkm3hH9VpTCizq+6x K7LaBMkAkU1OF33T9GtB4AlTm9pLtmcSp3pCEuPYPas/ckSqzH3sWEo8l9O0Nbk8QKdA 31aeZahfGSgtFaEHVhcf7DaQSe54zhAlaA02kJrlraKqXjsDgsofX6reIwtuPZ1rckbJ m33w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iOU9fyL4; spf=pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.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 y73-v6sor1574741ioe.69.2018.04.26.07.32.48 for (Google Transport Security); Thu, 26 Apr 2018 07:32:48 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a6b:fd0:: with SMTP id 77-v6mr37216241iop.108.1524753167152; Thu, 26 Apr 2018 07:32:47 -0700 (PDT) In-Reply-To: X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iOU9fyL4; spf=pass (google.com: domain of calabrese@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Original-From: Matt Calabrese 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:38020 Archived-At: --000000000000e66d50056ac14209 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018, 22:45 Nevin Liber wrote: > 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*. > I agree with you, and I understand that this is also what you want -- to be very clear, my issues with variant were whether or not we want to introduce a "valueless by exception" state at all. Now that it is in C++17 with a valueless by exception state, I don't actually care how frequently we get into it. At this point, it's one of the valid states of the object (regardless of what we call it) and we may as well go into the valueless by exception state any time that an exception is thrown in the places where, internally, no alternatives are active at the time that the exception would propagate. I don't think this is even particularly weird -- it's just something you'd expected from the basic exception guarantee, and like anywhere else, I agree with you in that I don't think it's worthwhile to do extra work to strengthen the guarantee in order to avoid it, since we already have the valueless by exception state anyway. The usual process in these cases is to just specify the guarantee that naturally comes up. That said, as I understand it, the intent voiced by many of those who were in favor of valueless by exception was actually to still minimize the places where we get into the valueless by exception state. As is, variant already very explicitly avoids the valuless by exception state and is not afraid to perform extra moves operations to do so. For instance, when the copy constructor can throw and the move is noexcept (an extremely common case, mind you, and possibly even the most common case in many code-bases), we do not simply destroy and then copy construct, specifying the valueless by exception state in places where the copy constructor throws. Instead, we copy-construct to a temporary and then move-assign so as to avoid the valueless by exception state. This was not by accident, is not free, and very explicitly uses moves in the way that you have expressed that you personally wish to avoid. It is not at all obvious to me that the opinion you and I have expressed actually is intent, and if it was, then overall we are still being inconsistent. If we are okay with that then it is fine. My personal thoughts are that, excluding certain standard library node-based containers and things that contain them, places where neither the copy nor move are noexcept are often likely to be the legacy case where people define a copy constructor but not a more efficient move constructor, and so the move there is more likely to be costly in practice (i.e. it's more likely to be a true copy even though a more optimal move operational could have hypothetically been written but was not). So for the sake of practicality, I could imagine some people preferring this even when overall they wanted to minimize entering the valueless by exception state. That said, if those people actually cared about performance, they probably would have added a move constructor were it in their power to do so. This specific point may have even been discussed -- I do not recall and we can go back and check the notes from the meetings, but the backlash I'm seeing here is quite frankly absurd. We are not in committee, we are not even in the internal reflectors. We are on a public list before any deep research. We are not "wasting committee time". This is about as far away from wasting committee time as possible while still being able to get interested parties involved in an early discussion if they so choose. On Wed, Apr 25, 2018, 22:45 Nevin Liber wrote: > Oh, and that move operation may *terminate*, because noexcept only > guarantees that an exception will not escape the function call. > I'm not sure what point you are making here. Are you just giving this as an example of why it is a breaking change? Yes, it certainly is. I've already expressed that it is. Even if it doesn't terminate we would change operations that were explicitly specified to take place. On Wed, Apr 25, 2018, 22:45 Nevin Liber wrote: > Consensus isn't about getting what you want; it's about getting what you > can live with. > We're going off on a tangent now, but I find that point of view regarding the committee and consensus somewhat disappointing. Yes, consensus isn't about getting exactly what you want, however the primary goal of participating in the committee is not "coming to a consensus" -- it's about trying to make the language as solid and as consistent as it can be and to standardize existing practice. Consensus is just our best shot at getting there. Sometimes consensus leads us to an odd or inconsistent state that people didn't fully anticipate. Sometimes, we unfortunately design by committee instead of standardizing existing practice. Members should not be afraid to identify those cases and try to fix them "because consensus". This is especially true in cases where "consensus" is often an extremely small subset of the committee, which itself is already an extremely small subset of the C++ community (not referring to variant in this case, but rather other goings-on in the committee as papers make their way through subgroups). One would hope we are better than that. On Wed, Apr 25, 2018, 22:45 Nevin Liber wrote: > 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. > Who said that adding noexcept(false) would avoid a pessimization? The case we are talking about "pessimizing" is precisely where both copies and moves are *already* noexcept(false). And to be clear, library already "pessimizes" in an actual common case (noexcept move, non-noexcept copy) because of how variant defines operator= when move is noexcept but copy is not. We do the extra move in this case -- that is the reality, whether you or I like it. When both are noexcept, though, we do not make any sacrifices, and that would never change. I don't understand where you are expecting to have to tell people to add noexcept(false), whether today or in some hypothetical future. Someone correct me if I'm wrong here and am missing something subtle. On Wed, Apr 25, 2018, 22:45 Nevin Liber wrote: > 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. > I wasn't at JAX this time around, but I do agree. Ideally, if we just did a very quick "over my dead body" poll in plenary before the week even started, I would have expected it to be killed before any broader discussion took place. I didn't check to see if something like this actually happened for signed integer wrap, but I would have thought this would have killed the discussion pretty quickly. If that poll happened and it didn't kill it outright, then I am genuinely surprised. -- 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/CANh8DEmuDWSVCgg41dqv9pBwWB1x6%3DS1anau_R6_X_1ZX1EK6w%40mail.gmail.com. --000000000000e66d50056ac14209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com>= ; wrote:
On Wed, A= pr 25, 2018 at 5:47 PM, 'Matt Calabrese' via ISO C++ Standard - Fut= ure Proposals <std-proposals@isocpp.org><= /span> wrote:


On Wed, Apr 25, 2018, 18:00 Nevin Liber <nevin@eviloverlord.com> wrote:
On Wed, Apr 25, 2018 at 4:51 PM, 'Matt Calabrese' via ISO = C++ Standard - Future Proposals <std-proposals@isocpp.org> 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 con= cern is that the current specification implies that we can get to valueless= _by_exception in an assignment even when a move constructor does not actual= ly throw, which is currently true. Should we "fix" this in a futu= re standard or consider to be fine?

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

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

I'll r= estate: I'm pretty sure you are misunderstanding the specific case we a= re talking about. Forget about Boost.Variant or a lack of valueless by exce= ption -- that ship sailed and this has little to do with it. I am not at al= l saying we should try to change consensus on something that already shippe= d. Look again at the example -- we are getting to the valueless by exceptio= n state from an assignment operation without ever even having a move operat= ion that throws, which many advocates of valueless by exception did not wan= t. We certainly can avoid this if the committee decided (this is in line wi= th expressed intent and we've already made other changes to minimize va= lueless by exception).

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 t= he moves?=C2=A0

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

Maybe I'm misinterpreting the above, but the way being propose= d to avoid valueless_by_exception is by introducing an extra move operation= to temporarily double buffer, which is a performance pessimization on t= he far more common case of not throwing.

I agree wit= h you, and I understand that this is also what you want -- to be very clear= , my issues with variant were whether or not we want to introduce a "v= alueless by exception" state at all. Now that it is in C++17 with a va= lueless by exception state, I don't actually care how frequently we get= into it. At this point, it's one of the valid states of the object (re= gardless of what we call it) and we may as well go into the valueless by ex= ception state any time that an exception is thrown in the places where, int= ernally, no alternatives are active at the time that the exception would pr= opagate. I don't think this is even particularly weird -- it's just= something you'd expected from the basic exception guarantee, and like = anywhere else, I agree with you in that I don't think it's worthwhi= le to do extra work to strengthen the guarantee in order to avoid it, since= we already have the valueless by exception state anyway. The usual process= in these cases is to just specify the guarantee that naturally comes up.

That said, as I understand it, the int= ent voiced by many of those who were in favor of valueless by exception was= actually to still minimize the places where we get into the valueless by e= xception state. As is, variant already very explicitly avoids the valuless = by exception state and is not afraid to perform extra moves operations to d= o so. For instance, when the copy constructor can throw and the move is noe= xcept (an extremely common case, mind you, and possibly even the most commo= n case in many code-bases), we do not simply destroy and then copy construc= t, specifying the valueless by exception state in places where the copy con= structor throws. Instead, we copy-construct to a temporary and then move-as= sign so as to avoid the valueless by exception state. This was not by accid= ent, is not free, and very explicitly uses moves in the way that you have e= xpressed that you personally wish to avoid. It is not at all obvious to me = that the opinion you and I have expressed actually is intent, and if it was= , then overall we are still being inconsistent. If we are okay with that th= en it is fine.

My personal thoughts are that, excl= uding certain standard library node-based containers and things that contai= n them, places where neither the copy nor move are noexcept are often likel= y to be the legacy case where people define a copy constructor but not a mo= re efficient move constructor, and so the move there is more likely to be c= ostly in practice (i.e. it's more likely to be a true copy even though = a more optimal move operational could have hypothetically been written but = was not). So for the sake of practicality, I could imagine some people pref= erring this even when overall they wanted to minimize entering the valueles= s by exception state. That said, if those people actually cared about perfo= rmance, they probably would have added a move constructor were it in their = power to do so. This specific point may have even been discussed -- I do no= t recall and we can go back and check the notes from the meetings, but the = backlash I'm seeing here is quite frankly absurd. We are not in committ= ee, we are not even in the internal reflectors. We are on a public list bef= ore any deep research. We are not "wasting committee time". This = is about as far away from wasting committee time as possible while still be= ing able to get interested parties involved in an early discussion if they = so choose.

On Wed, Apr 25, 2018, 22:45 Nevin Liber <<= a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo= rd.com> wrote:
Oh, and that move operation may = terminate, because noexcept only guarantees that an exception will not = escape the function call.
<= div dir=3D"auto">
I'm not sure what point yo= u are making here. Are you just giving this as an example of why it is a br= eaking change? Yes, it certainly is. I've already expressed that it is.= Even if it doesn't terminate we would change operations that were expl= icitly specified to take place.

On Wed, Apr 25, 2018, 22:4= 5 Nevin Liber <nevin@eviloverlord.com> wrote:
Consensus isn't = about getting what you want; it's about getting what you can live with.=

We're going off on a tangent now, but I find that point of view = regarding the committee and consensus somewhat disappointing. Yes, consensu= s isn't about getting exactly what you want, however the primary goal o= f participating in the committee is not "coming to a consensus" -= - it's about trying to make the language as solid and as consistent as = it can be and to standardize existing practice. Consensus is just our best = shot at getting there. Sometimes consensus leads us to an odd or inconsiste= nt state that people didn't fully anticipate. Sometimes, we unfortunate= ly design by committee instead of standardizing existing practice. Members = should not be afraid to identify those cases and try to fix them "beca= use consensus". This is especially true in cases where "consensus= " is often an extremely small subset of the committee, which itself is= already an extremely small subset of the C++ community (not referring to v= ariant in this case, but rather other goings-on in the committee as papers = make their way through subgroups). One would hope we are better than that.<= /div>

On Wed, Apr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com<= /a>> wrote:
<= /blockquote>

Who said that adding noexcept(false) would = avoid a pessimization? The case we are talking about "pessimizing"= ; is precisely where both copies and moves are *already* noexcept(false). A= nd to be clear, library already "pessimizes" in an actual common = case (noexcept move, non-noexcept copy) because of how variant defines oper= ator=3D when move is noexcept but copy is not. We do the extra move in this= case -- that is the reality, whether you or I like it. When both are noexc= ept, though, we do not make any sacrifices, and that would never change. I = don't understand where you are expecting to have to tell people to add = noexcept(false), whether today or in some hypothetical future. Someone corr= ect me if I'm wrong here and am missing something subtle.

On Wed, A= pr 25, 2018, 22:45 Nevin Liber <nevin@eviloverlord.com= > wrote:
For instance, in JA= X 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 mig= ht 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= wrapping the built in signed types would pass (it didn't) and now we d= on't have any progress on adding ops/types that wrap.
=

I wasn't at JAX this time around= , but I do agree. Ideally, if we just did a very quick "over my dead b= ody" poll in plenary before the week even started, I would have expect= ed it to be killed before any broader discussion took place. I didn't c= heck to see if something like this actually happened for signed integer wra= p, but I would have thought this would have killed the discussion pretty qu= ickly. If that poll happened and it didn't kill it outright, then I am = genuinely surprised.

--
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/CANh8DEmuDWSVCg= g41dqv9pBwWB1x6%3DS1anau_R6_X_1ZX1EK6w%40mail.gmail.com.
--000000000000e66d50056ac14209-- .