220 38002 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: Wed, 25 Apr 2018 20:33:42 +0000 Lines: 124 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="0000000000006b1251056ab23064" X-Trace: blaine.gmane.org 1524688309 28725 195.159.176.226 (25 Apr 2018 20:31:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Apr 2018 20:31:49 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBMOMQPLQKGQEHWMGUPQ@isocpp.org Wed Apr 25 22:31:44 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fBR4q-0007L7-7S for gclcip-std-proposals@m.gmane.org; Wed, 25 Apr 2018 22:31:44 +0200 Original-Received: by mail-it0-f69.google.com with SMTP id d131-v6sf2148138itc.8 for ; Wed, 25 Apr 2018 13:33:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1524688434; cv=pass; d=google.com; s=arc-20160816; b=uPbnVWSFCR0Dw8Erlfaa27J2lehZmCwbhI/MamwM2Wvcgq/mbiapnRC3YMvAFnQyco wKn+7BQkNlejzku4uSJEU4mI7v9Nl0+EwzobO7RkZa3GVoGmUBZgwPiADHiJeftsQc4L o9R9UT2m7TyEBXWsSqgSfDNpA4tEiw6T9cOLNZIKg6Fj0Sp1w2i0iBWmKpJOpNsSEZLW DuEbzPEiSkEjapxmkx+zmKcV/bkrVIL8DMLnvg29erAtNt30MI8BYB42s8fmAONI0Px5 65Pyy+/cu4juDF1r+qkkBAzhpL07rYV8VLukAKIhFofSG96uNkx52vpf1OuHhKsC0fQi ZfIA== 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=/yv2W7pA1ZN5GUDawp+CzHkGexTbXxOefD8V01kaRCg=; b=KOa6pYfjQ23gx53Edj7eYHfiGSPJqoCNQM+EpsHpu0bEDHeH5jdmRPHHAA9BCDlu/B SvkNApKLRhq7XkQaw/zwSDankwR/HfFhCSKtMHWrYWTGJUjJizEaOfDgNdQ1pzG5wfhV SiZ9YMrRNU6giE0GofZSJxlA2JnOWFl/dxI3Ezok1ncrSmUVjoTjBoU5hrn/SWImHVs9 NCMorpV8RTcRz8LSviXCBkU0ZBHBapqk/OW8ahSXMKKfAgdiDtG5gxwVtY3g7vdJ1jot Ty0tQ3RiQHsSOBenvzjvQzdjV8htympRk1TJSDsoDN9kwylD+p2NifT8R8o+LAokgycl resw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cQEo+MPz; 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=/yv2W7pA1ZN5GUDawp+CzHkGexTbXxOefD8V01kaRCg=; b=JT7sYrSYQwC0UJsnDLe/QTqsFDtolI3mkZBM8fSKlsvP7lrLaWnYVZ+rw8vlJEXv1P K0dE6NDcG1W4j/oTDvHSv9vn26ZCay42FxYmGVD9g96CkmyGKQIYEJsgd1WbZ6lodaAz gOy8bx+J49FYGTvs0n/k6xpkQ15DS6rooGdjRPjwvxOkjEBlavNtB8226FKanXUcgtc5 weY8E8JbKJ93Ez9e7CViH45EIUf5HD6V+Dk4KIXjtnfn1PiwhKRGqdvwyaRi/bkGLUaN 9iPBZEhXQsKmmw0KII3ljzl5SsNqftUmNSIyw8q9nYiSgUJwXlsp6w9Xq4CSJMCzeDHW +BLA== 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=/yv2W7pA1ZN5GUDawp+CzHkGexTbXxOefD8V01kaRCg=; b=mUzdJI6c+1iCYolM5AummEsgXQ4BDGxuSJrelWGM3X5drd3vMVHMl4MQO+xOoyQPIH 6Z7dzF58ro0i2f+621JZMls0b53zNvbvLIxFZv6I0J+9vqQs3dbAAiSdP8Jwfqf0ZvZy u+4EEjF5RhXzBySOhQWqs6UOGCXOZq3ElPQ38Z3vrhSdydo22MJMCS1JD9xSl2w09D/7 NhVFuBntfwrGvjfW/tg59p966dEvfKFt34Vgyw1fPVfiNxhB4CMFjUGIWh/6c7tRUgn7 ArKlVx0q+mJHkUPODmKLuiZOPgl3CjbjiwcuZ0mk0mwvKGxUJqkEAZXx86HMptxkRMRa fhew== X-Gm-Message-State: ALQs6tC+qwV6L1Q8QA7KRgCcWr/TMNyF21KCzgeBfadByEvxPhS1MtMx 3dYx/KNML6Z5hrldizgTWPU= X-Google-Smtp-Source: AB8JxZpaDuiYlXebZt8D2rlj8VqD4a9OZ3JVS4wEJorF3+9xIMFaumuyj413SGPkTMdVA6tLyptx3Q== X-Received: by 2002:a6b:8c0f:: with SMTP id o15-v6mr16588727iod.42.1524688434660; Wed, 25 Apr 2018 13:33:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a6b:4611:: with SMTP id t17-v6ls4260733ioa.23.gmail; Wed, 25 Apr 2018 13:33:53 -0700 (PDT) X-Received: by 2002:a6b:4e0c:: with SMTP id c12-v6mr20709918iob.49.1524688433434; Wed, 25 Apr 2018 13:33:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524688433; cv=none; d=google.com; s=arc-20160816; b=JowbzSLJkXAAtfFmA3V4DyzI6V/1w1amaUMEDP5TQG9tsp3p8qoNCqy+aD8hhUjgS0 I/IeXd0uFYF/mNrf6Y0P55CCgfy1lNRaxo3s8lQVOVLl3IRvF7xkuOvNJj3mI1t3OiUE DTWiRjf7/+Z6CnxymO7yDruaSgq63Jdjc06kEjE4oWj8wRZxw277gW37rO72P0W/omqu YmwXJLpFsFMpV8mDxmb93+CQ6XPrwvehO+QCYFK5CO84rPMVW6oIgbGuvXKT0ihj3PMD tOqgbftU+sxpxE/0YsPpYXeuLqMvuYVFOxvctwXLjXnpR89muVuW+1/o0PfIcmY0HycS E8oA== 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=nmBelV8RcwsPwMlSWNglizQO1+XFWeKOBFxl8jhCsWA=; b=zmZS64HQRTxBL9t8l2kXetsUfLwe1QqXsHnCpaZTc7H5SWYiX6znJzRNUaCi5fqFpO XL5TfNgIPyUVFCZHikGgNalVEo9AwLMwX7b3P2Z6mh5cIjmJCIzd7/sxTY+yxyFi0wCo eunCZPsCcC89aa/rAi3ej2IiaLfuE8q85tHJ/1rm+LB+5JJdHixK2WWZxi0es8yhEiTG FA3tIr92b9GrExbwYncWNXS+kMSBC6ZtMy6C77YBwlCh1/Yu8C8OH9VrgpPXm/SnW1rC smDUp0XCJzz3KD5XkNJLZUH7Vckr1hjVkp6z/26vNKfRYhAGADOHENtAv497kgt/sJS7 9Ksg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cQEo+MPz; 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 o10-v6sor5565384iti.21.2018.04.25.13.33.53 for (Google Transport Security); Wed, 25 Apr 2018 13:33:53 -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:a24:df04:: with SMTP id r4-v6mr24158681itg.105.1524688432559; Wed, 25 Apr 2018 13:33:52 -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=cQEo+MPz; 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:38002 Archived-At: --0000000000006b1251056ab23064 Content-Type: text/plain; charset="UTF-8" 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. 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. Alternatively, we can come up with even more rigid rules for what specifically happens in each case, but I suspect we are already over-specifying here. Implementations also might actually choose to go into the valueless_by_exception state when given other options because it's possibly more efficient to do so, and I'm not sure that's too horrible of an idea given that the valueless_by_exception state is already a reality anyway. As someone who is not particularly fond of valueless_by_exception, my overall opinion is *shrugs*. -- 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/CANh8DEkGVR5_vqErg634Eh%2BzXrGfn%3D5eetnGYcEf%3DR422vkvtA%40mail.gmail.com. --0000000000006b1251056ab23064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 25= , 2018 at 1:51 PM Tony V E <tvaneerd@gmail.com> wrote:


On Wed, Apr 25, 2018 at 10:40 AM, 'Matt Calabrese'= via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org<= /a>> wrote:
Also, it will = only get into that state because some move-operation threw.

*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 might be t= o only specify the basic guarantee in places where we currently specify, ve= ry explicitly, that we end up in the "valueless_by_exception" sta= te. 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 divergenc= e anyway. This for emplace as well as for assignments.

=
Anyway, it's already a little bit out of the ordinary that we woul= d dictate a specific state rather than just one of the normal guarantees wh= en you look elsewhere in the standard library and in other libraries. Alter= natively, we can come up with even more rigid rules for what specifically h= appens in each case, but I suspect we=C2=A0are already over-specifying here= .. Implementations also might actually choose to go into the valueless_by_ex= ception state when given other options because it's possibly more effic= ient to do so, and I'm not sure that's too horrible of an idea give= n that the valueless_by_exception state is already a reality anyway. As som= eone who is not particularly fond of valueless_by_exception, my overall opi= nion is *shrugs*.

--
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/CANh8DEkGVR= 5_vqErg634Eh%2BzXrGfn%3D5eetnGYcEf%3DR422vkvtA%40mail.gmail.com.
--0000000000006b1251056ab23064-- .