220 38004 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 15:59:38 -0500 Lines: 162 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="f403043c6b50f644ff056ab28e4b" X-Trace: blaine.gmane.org 1524689894 5178 195.159.176.226 (25 Apr 2018 20:58:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Apr 2018 20:58:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCE35H5S6IDBBY6YQPLQKGQELWHORZA@isocpp.org Wed Apr 25 22:58:10 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 1fBRUP-0001Eq-VN for gclcip-std-proposals@m.gmane.org; Wed, 25 Apr 2018 22:58:10 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id g34sf19500167uaa.9 for ; Wed, 25 Apr 2018 14:00:21 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1524690020; cv=pass; d=google.com; s=arc-20160816; b=MbYe6IiyfWAZ3KPc2xk/eO1NAyd02xIT5yFW5hTevZXtsXNEc/FixeYYDZ640rrWGM 4Y4JaSbY6effvdNH2XaSnXuScAeLPOFawxd0mccL4HozW3/RWDWmg+/2Pp6gni5yrQgu MJ4XQL3qNPly26bdegdLi+lKfAsCRVihlgYWJobZwkIJPL5fGfoVHIxbJrTcO2N9V3Cy nZUWzcJeawMOXXe9incTAAR+FWms1m0Zkl+nf+pLwGaOkVdcP4+GoTgzgkkPYYHDg24r Fwg06e9srMWyJuoBoVtE278faYNt67UhNjtGuv07eVNE0HPygzh10nIJRR7fHyuRjWHd SJgQ== 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=QFwjrPpg1gR1V6WKUCdeihP9ueSEd+kndM1RB3aK7E8=; b=IoYhKiNzSm9q8rQiHTKZCxj3FX26RMo5d1k8IbJFPLzriFcXCNOa5dyKzsLc0JW37a 62KY0Z4HQe8daRFqnDWZMxDRaVZd1bm1bo2bcC6brNYEsknHucRgkneH3AUql18GgQ6z rZk0u/ul7D84FdnPOg+4maBqs7LMZsrlJrBmwFhOHge7l/SV2Jd5s2ob/SXgKXNAAJqy VhlmZNYFch45fkQH/lZcCPKdt/JdpWruKF3uTAx6bz0FOhQ5bK7I3affNU6MgvOj+zRB YLe+lVB9Vx8cgIkzKIUxkVBg8eqw2Ld9auTv/CK4U/v6C7tX1WZ4c6JCzri4Nz1/dtlH 4vvw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=J40i0sho; 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=QFwjrPpg1gR1V6WKUCdeihP9ueSEd+kndM1RB3aK7E8=; b=HpFp2MutVDLkNGjMb4hBDXvrlH4naJNu1VXRLlmr7hbaC0tEM8mwoe9et4TZppyFZl E8/tNk3j6S1lBp3nDOdg7tAQL42+UDNUS1dgGLG96tl1Fea1bR6KVgDhqzERts+/pgOk fqH10lVQtt2drTk2Fr/kD5MLV9l3c0IWuP6Qud3sROcI1vV7GSqBKUVI0DPOcTFZLzlM cOHO3IGRkO5Fr/IxExRbpTIDAAiGjS0ZyVN9HrA0Q5C9Rs2y7lc3llsd1ZSm7IaI0H3I LbrJ4TDFJiJQNqoW+uDl18Y0q0LbGKtj+iMT4DCn57L0c2pMkMs5WC/1taWwa7MBvTcr 7nsA== X-Gm-Message-State: ALQs6tBtR1FUa7gruHUL8HIrxKd0euOLsw1hDOsguQp8YRzfnFlq9mC4 zCzsw1Wp5K+bOkacZrwIO4Q= X-Google-Smtp-Source: AIpwx49lEh+oLY3HmucM3q6krH9HH8FeqJnFserl/56vFiuje5HIndJ7XoQFGMAv87pw1FFqXsl/vw== X-Received: by 10.31.168.9 with SMTP id r9mr15121261vke.69.1524690020757; Wed, 25 Apr 2018 14:00:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.49.74 with SMTP id e10ls3005437uam.10.gmail; Wed, 25 Apr 2018 14:00:19 -0700 (PDT) X-Received: by 10.159.42.130 with SMTP id z2mr12378885uai.182.1524690019555; Wed, 25 Apr 2018 14:00:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524690019; cv=none; d=google.com; s=arc-20160816; b=F6cZxPiJ2JUNiRcd1UuwowgAMSoXCTGwY5j6kEtqFifTEKs21waGLeKvV8aPJUuVce JMMlcgw2V1fB9/jqOleA7M0X2u4z6dkvkDECg5eKHf0RD+ZqoWYQ9IpI3I7wSlSNzYtM 2WQImWHfWKQ6r41k9FlzDclwEfBavhgNXTJfvNp4bLc7hZCYoqVjucayocCMDQPMwp4s g/t8k/6K5NRpK7nwwpp9Vlmw9tqdmZVeepPN/gXm4JzGg75CGgxARlt1+wGHl80dD9Vd i7xKGDC+JWacQngWrSrh9wLrH/ug8v/VVMwWyAJmFrsWRkRT0+wzZFpgrrCf0E1Vyeiv QYtw== 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=NQ1oGHmp1nJvROopDq7ju73rQ31bvfMhtpLCcyg/Fws=; b=jjnKm23P93cS6Q6/DyXqXcHGZCSJRTPXSy7vjsF8ylwXSIsG0xPq8CRnOuZqGfAUAY Cin2fCbLNmMMZgQF8ccdcSoKWY0leZN6jYnIFrNQIPJPPLNYLHbb2y8mqtXNulIWvJ35 YxgFnun2hc5lN74p2MC5y6U0L1SRCjLbiQeTUGac7vQt1C0kSHMQdaIM7PJitXI7pWCx vMBVp4WmUVk87llxV1X1A7pw56r+kW5+TYQ12uPHjdbf56YjluhE8b7aMPhPk7ZgKveL 9wMXFiT506n77A+NxRAEroS4XRdEBd3fOX7X0Xj2atI78SW6PFDE2aXS9YOVBZ6Kfhe3 Dinw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=J40i0sho; 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 60sor6509299uab.120.2018.04.25.14.00.19 for (Google Transport Security); Wed, 25 Apr 2018 14:00:19 -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.77.77 with SMTP id k13mr22578465uag.136.1524690018778; Wed, 25 Apr 2018 14:00:18 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.103.118.200 with HTTP; Wed, 25 Apr 2018 13:59:38 -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=J40i0sho; 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:38004 Archived-At: --f403043c6b50f644ff056ab28e4b Content-Type: text/plain; charset="UTF-8" On Wed, Apr 25, 2018 at 3:33 PM, 'Matt Calabrese' via ISO C++ Standard - Future Proposals wrote: > On Wed, Apr 25, 2018 at 1:51 PM Tony V E wrote: > >> >> >> On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard - >> Future Proposals wrote: >> >>> On Tue, Apr 24, 2018 at 1:32 PM Tony V E wrote: >>> >>>> Also, it will only get into that state because some move-operation >>>> threw. >>>> >>> >>> *cough* >>> >>> libc++: https://wandbox.org/permlink/0ag3V2oVa3MBcWmz >>> libstdc++: https://wandbox.org/permlink/LEUsrj9ir5vyVcST >>> >>> >>> >> >> Why doesn't variant revert back to the int when the copy throws? We >> don't want to pay for the moves? >> > > Not taking any specific stance here -- if we want to at least allow > implementations to have valueless_by_exception in fewer cases without being > non-compliant, I think the easiest catch-all might be to only specify the > basic guarantee in places where we currently specify, very explicitly, that > we end up in the "valueless_by_exception" state. It's technically breaking, > but people actually relying on something necessarily being in the > valueless_by_exception state, outside of standard library tests, seems > dubious, and we already have implementation divergence anyway. This for > emplace as well as for assignments. > Do you and Tony really wish to re-argue variant??? > Anyway, it's already a little bit out of the ordinary that we would > dictate a specific state rather than just one of the normal guarantees when > you look elsewhere in the standard library and in other libraries. > The normal guarantees (valid but unspecified state) don't cover it in general; you have to have a state when you cannot guarantee construction of any of the types in the type list. That forces variant to model at-most-1 instead of exactly-1, and no other states cover variant holding none of the types in the type list. Double buffering was a non-starter. The endless discussions about non-throwing move constructors went nowhere. Given those constraints, valueless_by_exception is (a) the easiest to reason about and (b) the most annoying to deal with. And all that was already discussed ad nauseam. I see no new information being presented here. I would be strongly against spending any committee time on this w/o new information. -- 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%2BMhymTGPCiDRgkTvV0QuXzNJ_BC%2Bhm2mEGuErJ6K3YFtw%40mail.gmail.com. --f403043c6b50f644ff056ab28e4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 25, 2018 at 3:33 PM, 'Matt Calabrese' = via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org> wrote:


On Wed, A= pr 25, 2018 at 10:40 AM, 'Matt Calabrese' via ISO C++ Standard - Fu= ture Proposals <std-proposals@isocpp.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= span>
On Tue, Apr 24, 2018 at 1:32 PM Tony V E <tvaneerd@gmail.com>= wrote:
Also, it will only get into that state = because some move-operation threw.

<= /span>
*cough*=C2=A0




Why doesn't variant revert back to the int when the co= py throws?=C2=A0 We don't want to pay for the moves?

Not taking any specific stance here -- if = we want to at least allow implementations to have valueless_by_exception in= fewer cases without being non-compliant, I think the easiest catch-all mig= ht be to only specify the basic guarantee in places where we currently spec= ify, very explicitly, that we end up in the "valueless_by_exception&qu= ot; state. It's technically breaking, but people actually relying on so= mething necessarily being in the valueless_by_exception state, outside of s= tandard library tests, seems dubious, and we already have implementation di= vergence anyway. This for emplace as well as for assignments.

Do you and Tony really wish to re-argu= e variant???
=C2=A0
Anyway, it's already a little = bit out of the ordinary that we would dictate a specific state rather than = just one of the normal guarantees when you look elsewhere in the standard l= ibrary and in other libraries.

The normal guarantees (valid but unspecified state) don't cover i= t in general; you have to have a state when you cannot guarantee constructi= on of any of the types in the type list.=C2=A0 That forces variant to model= at-most-1 instead of exactly-1, and no other states cover variant holding = none of the types in the type list.

Double bufferi= ng was a non-starter.=C2=A0 The endless discussions about non-throwing move= constructors went nowhere.

Given those constraint= s, valueless_by_exception is (a) the easiest to reason about and (b) the mo= st annoying to deal with.


And all t= hat was already discussed ad nauseam.=C2=A0 I see no new information being = presented here.=C2=A0 I would be strongly against spending any committee ti= me on this w/o new information.
--
=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 https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMhym= TGPCiDRgkTvV0QuXzNJ_BC%2Bhm2mEGuErJ6K3YFtw%40mail.gmail.com.
--f403043c6b50f644ff056ab28e4b-- .