220 18781 article Path: news.gmane.org!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Compressing std::optional Date: Thu, 25 Jun 2015 10:34:39 -0500 Lines: 190 Approved: news@gmane.org Message-ID: 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=001a11c23d9cedfd750519595e39 X-Trace: ger.gmane.org 1435246531 13358 80.91.229.3 (25 Jun 2015 15:35:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 15:35:31 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCE35H5S6IDBBN57WCWAKGQEBAJHGTI@isocpp.org Thu Jun 25 17:35:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f72.google.com ([209.85.215.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z89BT-0001HE-1b for gclcip-std-proposals@m.gmane.org; Thu, 25 Jun 2015 17:35:23 +0200 Original-Received: by laka10 with SMTP id a10sf19998868lak.2 for ; Thu, 25 Jun 2015 08:35:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject: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=cCuJDmnNjeNo4sXG79u/YlAkCiG+g1vVAtOn+rq7nBw=; b=QoQA1vMzMRDfSQaN8SARysaBI7It6jSl3EU+uPSc4BK6pEUrquYqK0P4vwxjppK8wb X7VyvMWhTBh3TUDL0rK8dYd7nWCSiII89PCzzIjozZqGzuZSlFJqN1rsz4CMk1Mm5AmS 30DaIXNRnyx/qkNFWeZHRKYHW8TgbODyHcMWBnxJjew+ptDtYVDo4F/CNCwuJcT9hJnO E2AZddbDnqs0Wibtm+9Arp81kA+WCiiS7vzTLHf+mh0c9tvo/cvJXaujYwnhPIor+xlF QynNvRyR+HRUYvmR3tZviAMnLEFQAkskNlhPUFfYCNBDKMw39n1LP8e+CS6oGpIh2kpU waag== X-Gm-Message-State: ALoCoQk5+cBE5fW2+m5joJL1df95mjSWslvLXZrfvUnT9GXh72hLXEKwzHa3zjknOP7gXnI2LNWy X-Received: by 10.112.42.236 with SMTP id r12mr40227341lbl.2.1435246522384; Thu, 25 Jun 2015 08:35:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.184.164 with SMTP id ev4ls355032wic.16.canary; Thu, 25 Jun 2015 08:35:19 -0700 (PDT) X-Received: by 10.180.86.163 with SMTP id q3mr6785958wiz.75.1435246519443; Thu, 25 Jun 2015 08:35:19 -0700 (PDT) Original-Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com. [2a00:1450:400c:c00::22b]) by mx.google.com with ESMTPS id fr8si9262551wib.3.2015.06.25.08.35.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 08:35:19 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 2a00:1450:400c:c00::22b as permitted sender) client-ip=2a00:1450:400c:c00::22b; Original-Received: by wgbhy7 with SMTP id hy7so65894630wgb.2 for ; Thu, 25 Jun 2015 08:35:19 -0700 (PDT) X-Received: by 10.180.9.6 with SMTP id v6mr6874518wia.83.1435246518990; Thu, 25 Jun 2015 08:35:18 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.194.16.41 with HTTP; Thu, 25 Jun 2015 08:34:39 -0700 (PDT) In-Reply-To: X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 2a00:1450:400c:c00::22b as permitted sender) smtp.mail=nliber@gmail.com; dkim=pass header.i=@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:18781 Archived-At: --001a11c23d9cedfd750519595e39 Content-Type: text/plain; charset=UTF-8 On 25 June 2015 at 09:31, Tony V E wrote: > Are you only against it because it might delay optional, or for > technical/design reasons? > Both. If optional significantly changes, then any user experience we have so far gets thrown out the window. I'm fine if that happens because of the user experience, but I'm not fine with that for the purposes of invention. Especially if optional is a vocabulary type being targeted for C++17. As for technical considerations: One of the mental models we used for designing optional was that it is a T with an extra state. This customization breaks that model. We would have to revisit every single line of optional to see if it still holds true. For purposes of this, lets assume I want an optional where string("Geronimo") is the unengaged state. Let us start with the simplest constructors: constexpr optional() noexcept; constexpr optional(nullopt_t) noexcept; They are obviously no longer noexecept(true). Do we make that conditionally noexcept? If so, how? This customization will be as complicated as allocators (such as a noexcept_on_nullopt_t_construction_or_assignment member type derived from bool_type). How about assignment? Take optional& operator=(nullopt_t) noexcept; Besides the noexcept issue, what state is the optional left in when an exception is thrown? Beats me. And those are the simpler things. We haven't even gotten to the more controversial stuff, like heterogeneous comparisons and ordering. And there may language issues. As proposed: template void set_initialized(T*, bool initialized) The T* being passed may be a pointer to uninitialized storage and not a T. Is that legal? LEWG likes to "time box" discussions (which I strongly disagree with, because it basically means we aren't giving the author enough feedback to make useful progress, making it poor use of both the author's time and the committee's time. If we don't have the time to adequately discuss things, why are we soliciting for more stuff?). Based on how much committee time has been and will be spent on optional and variant, do you really think we can get through this kind of proposal in only an hour or two? I don't. Now, a significant portion of the complexity goes away if it is a separate type, because a separate type can just store a T instead of a block of storage it has to manage, the ordering can be identical to T, etc. -- Nevin ":-)" Liber (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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --001a11c23d9cedfd750519595e39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 5 June 2015 at 09:31, Tony V E <tvaneerd@gmail.com> wrote:<= br>
Are you only against it because i= t might delay optional, or for technical/design reasons?

Both.

If optional si= gnificantly changes, then any user experience we have so far gets thrown ou= t the window. I'm fine if that happens because of the user experience, = but I'm not fine with that for the purposes of invention.=C2=A0 Especia= lly if optional is a vocabulary type being targeted for C++17.

As for technical considerations:

=
One of the mental models we used for designing optional was that= it is a T with an extra state.=C2=A0 This customization breaks that model.=

We would have to revisit every single line of= optional to see if it still holds true.

For purpo= ses of this, lets assume I want an optional<string> where string(&quo= t;Geronimo") is the unengaged state.

Let us s= tart with the simplest constructors:

  constexpr optional() noexcept;

  constexpr opti=
onal(nullopt_t) noexcept;

They are obviously no longer noexece= pt(true).=C2=A0 Do we make that conditionally noexcept?=C2=A0 If so, how?= =C2=A0 This customization will be as complicated as allocators (such as a n= oexcept_on_nullopt_t_construction_or_assignment member type derived from bo= ol_type).

How about assignment?=C2=A0 Take

    optional<T>& oper=
ator=3D(nullopt_t) noexcept;
Besides the no= except issue, what state is the optional left in when an exception is throw= n?=C2=A0 Beats me.

And those are the simpler th= ings.=C2=A0 We haven't even gotten to the more controversial stuff, lik= e heterogeneous comparisons and ordering.

And t= here may language issues.=C2=A0 As proposed:

=C2=A0 =C2=A0 template <typename T>
=C2=A0 =C2=A0=C2=A0void=C2=A0set_initialized(T*,=C2=A0bool=C2=A0in= itialized)

<= /span>
The T* being passed may be a pointer to uninitialized storage and n= ot a T.=C2=A0 Is that legal?

LEWG likes to "time box&= quot; discussions (which I strongly disagree with, because it basically mea= ns we aren't giving the author enough feedback to make useful progress,= making it poor use of both the author's time and the committee's t= ime.=C2=A0 If we don't have the time to adequately discuss things, why = are we soliciting for more stuff?).=C2=A0 Based on how much committee time = has been and will be spent on optional and variant, do you really think we = can get through this kind of proposal in only an hour or two?=C2=A0 I don&#= 39;t.


Now, a significant portion of the complexity goes away i= f it is a separate type, because a separate type can just store a T instead= of a block of storage it has to manage, the ordering can be identical to T= , etc.
--
=C2=A0Nevin ":= -)" Liber=C2=A0 <mailto:nevin@eviloverlord.com>=C2=A0 (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a11c23d9cedfd750519595e39-- .