220 18773 <558BB70B.700@gmx.net> article Path: news.gmane.org!not-for-mail From: Fabio Fracassi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Compressing std::optional Date: Thu, 25 Jun 2015 10:08:43 +0200 Lines: 186 Approved: news@gmane.org Message-ID: <558BB70B.700@gmx.net> References: <4359ebfb-5e20-42c1-84a0-16ef6201db33@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000201020909030505010200" X-Trace: ger.gmane.org 1435219765 21308 80.91.229.3 (25 Jun 2015 08:09:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 08:09:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNZFW4U4YJRBKXOV2WAKGQEL7CCYMI@isocpp.org Thu Jun 25 10:09:16 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f200.google.com ([209.85.212.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z82Dk-0003Kg-Aw for gclcip-std-proposals@m.gmane.org; Thu, 25 Jun 2015 10:09:16 +0200 Original-Received: by wiea6 with SMTP id a6sf19563854wie.1 for ; Thu, 25 Jun 2015 01:09:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type: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=L8NsyZlk2SQR5PYVsq4dGgbS+Oi5O4twr2/lMGZJL7w=; b=EZIBrfMD7RLovDyvEFm4L4PYpfPcD0OVtAQgXZVqU/9JTkTia53LPYuo79h4M0jy/R hZ9l89c00kUCHHLMqZ9da8qi+HbPjHq7RlfJWElpPKwULOcny4PJR83dfiHaAWXmG17v S638nKrmPf0MsVCrsODQGgS755UBdTIUHm45HPFmAeQfvQVLfTuFn2KVnEkldyBqdwIK BFUjTM/+EeVS9qWoC5YPmD6Qo6vWuPMddKXVv1to8WBvo66zNT/N+JrUHRzXgdRaD9pf 1JidmvcKAxc/EDVkHvb81qZtID3qc5vCOt+/E3HSO/iiBVNk1tnEPk/GFicg93u/7pQS 30JQ= X-Gm-Message-State: ALoCoQnBYTbn10wZy3AmwgI8VRrt+AycaVZlRkH58QNae0Tj3ex1NlZUT9wpQSm+Os60sFxfVPvo X-Received: by 10.152.219.166 with SMTP id pp6mr38992115lac.1.1435219755731; Thu, 25 Jun 2015 01:09:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.189.201 with SMTP id gk9ls584702wic.3.gmail; Thu, 25 Jun 2015 01:09:14 -0700 (PDT) X-Received: by 10.180.80.9 with SMTP id n9mr3331004wix.87.1435219754478; Thu, 25 Jun 2015 01:09:14 -0700 (PDT) Original-Received: from mout.gmx.net (mout.gmx.net. [212.227.17.22]) by mx.google.com with ESMTPS id ql9si51339852wjc.168.2015.06.25.01.09.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 01:09:14 -0700 (PDT) Received-SPF: pass (google.com: domain of f.fracassi@gmx.net designates 212.227.17.22 as permitted sender) client-ip=212.227.17.22; Original-Received: from [127.0.0.1] ([213.61.229.130]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lmazv-1YXs7e2te7-00aAUw for ; Thu, 25 Jun 2015 10:09:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: X-Provags-ID: V03:K0:x4sR3suGOR3ptjS8M6SiCZHtoC+oBoHRKC7/GHXLNsZ/0jKu7pK 1GWHsB2BCIy0WlYPjsh+zogkdSVDA2D1vlprRJZNv4Ndm/rcXHCvxuyurwJugg6ob1iSinj iHjil7Qy4FWD21f55HZNnlnrLVE4IJcPfjWHPzdbFgyXLSCQ7KLJrEDAKfmYUvXwQ4DBSBz 2CD+mHBvdRhf2TeM8eskA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kTvt0uox7vY=:X/VDpW70z0yGmtFeGbD0of WGxSe6anNE+DZPKW9Fh8NKEWWJ9lHPlU0PAmddFGwGhFSPEMpdUW5o0kg1Ch7bQOPgU2cc9T7 IgVjFe5hUH/Vx3gcKHc3ZvinFENbC36ebc8G9PMzDRjPZxQli/qKTpErXE2riMgDA6kXr96mm DbnGN4GUe2AX2OLFfEt/CB1totoMShfxy0b49s/bZYrZBgv0pAt1a2qFLw39dXDpANSdS1Ocl X30bPZ3fl9ae0tLKOSmPQq7G10p5X3+YDm1XqggjAaaMSmXaCjif4f9acCd2CadWM4KpbQHP0 cyDuyBoiVXMCmZgZKzC7xQhPTzzI+rFXZqJvUoOderMpUv8rNAiKvFueFdepNoSM4soJ56e7A sj9RSYuGvuJn9ujUH3P2QkfysPy2dRQ92iGlssEsskeT1pOrfIFSMj1kjTr6RWiSoGRyeeN9w hdDBNYSKgVAmNAc8mRWYzZ2wkV6aH8RoCU/1OVveNfbpHjh2hGBhu6RkRgWo+RaszpT+EhCcn KKWWJE9/pHPAa5uRjpCXAhcpByPph63I9/Nx/kOsA3VB/JePZlAN0OH9lTSvHv2zbLOP+uXKM IFowsPN0a3YqY3dolruZ2YGIVg/M6uoRBBF6d48cvR6E9VT9OBa8kxQR6mb5AXejSkQ5ag0kc 43/u7m/DEzXpg8Biu/qs9dUBsyQgOYk49DUiZ5HRQDSREcxDx72cP8JYNOvOSMH5WRfM= X-Original-Sender: f.fracassi@gmx.net X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of f.fracassi@gmx.net designates 212.227.17.22 as permitted sender) smtp.mail=f.fracassi@gmx.net 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:18773 Archived-At: This is a multi-part message in MIME format. --------------000201020909030505010200 Content-Type: text/plain; charset=UTF-8; format=flowed On 25.06.2015 03:47, Nevin Liber wrote: > On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard - > Future Proposals > wrote: > > I'd be happy to see a paper fleshing this out. I don't think anyone > was opposed to the idea, but it would have slowed down the initial > optional<> proposal if it had been included. > > > Ahem. I was strongly against it when it came up on this list two > years ago, and I'm still strongly against it now. This could be > slightly tapered by proposing a separate type instead of shoehorning > it into optional. I think a separate type should be part of the design discussion, but I for one would prefer this to be integrated into optional because I see this as a semantically identical optimization. > If it were to be shoehorned into optional, I'd be strongly against > optional going into C++17, and that would make me sad. > I on the other hand would be rather sad if we couldn't use optional to improve code like string::find without introducing overhead. > Either way, I believe that it would take a /significant/ amount of > committee time to discuss. You have to revisit every issue that > optional and variant touched, I don't think this is a fair characterization. There are some interactions and probably subtleties that need to be disscussed, but hardly every interaction. It is mostly an implementation detail. > including the issues with the empty state of variant, because now you > may not be able to no throw construct the disengaged state. I don't see how this follows, we could very well specify this to be no-throw, without inhibiting any of the motivating use-cases. Best regards Fabio -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --------------000201020909030505010200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 25.06.2015 03:47, Nevin Liber wrote:<= br>
On 24 June 2015 at 17:58, 'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals <std-= proposals@isocpp.org> wrote:
I'd be happy to see a paper fleshing this out. I don't think anyone
was opposed to the idea, but it would have slowed down the initial
optional<> proposal if it had been included.

Ahem.=C2=A0 I was strongly against it when it came up on this list two years ago, and I'm still strongly against it now.=C2=A0 This could be slightly tapered by proposing a separate type instead of shoehorning it into optional.
I think a separate type should be part of the design discussion, but I for one would prefer this to be integrated into optional because I see this as a semantically identical optimization.

If it were to be shoehorned into optional, I'd be strongly against optional going into C++17, and that would make me sad.

I on the other hand would be rather sad if we couldn't use optional to improve code like string::find without introducing overhead.

Either way, I believe that it would take a significant<= /i> amount of committee time to discuss.=C2=A0 You have to revisi= t every issue that optional and variant touched,
I don't think this is a fair characterization. There are some interactions and probably subtleties that need to be disscussed, but hardly every interaction. It is mostly an implementation detail.

including the issues with the empty state of variant, because now you may not be able to no throw construct the disengaged state.
I don't see how this follows, we could very well specify this to be no-throw, without inhibiting any of the motivating use-cases.

Best regards

Fabio

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--------------000201020909030505010200-- .