220 2370 <70537900-4796-40a3-80ed-dbe4b89cecdf@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Nicol Bolas <jmckesson@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: optional<T>, one more value or two states
Date: Sun, 27 Jan 2013 13:48:57 -0800 (PST)
Lines: 118
Approved: news@gmane.org
Message-ID: <70537900-4796-40a3-80ed-dbe4b89cecdf@isocpp.org>
References: <CAGsORuC1ADLXgS9AZZiTo=knmhT-+9Yj+82v+b8Nq_WJpb1fOg@mail.gmail.com>
 <CAFk2RUZyZA0LLUNuVNcnibv+qBF69jMytWQL3tkp-Kp21oEU+A@mail.gmail.com>
 <CAGsORuB-Qkx-LaXj2jO4yLrwN524kiJONSg7oczkQZHYaJ6ASg@mail.gmail.com>
 <d360a952-28ae-4d57-bb20-96fd08725a0b@isocpp.org>
 <CAPXezF_JggyMaXjGS9r1EAGVu1NhQBEyGEXB8tKmVqgFfjoCeg@mail.gmail.com>
 <CALJmx62zJd_tZ=XYL7TaSkRN6432SObwH9YS87eLX-h_pMuFYQ@mail.gmail.com>
 <CAOHCbivAK0ypmMhrhJ3zKpF8BHu3h_rUNzeao-HnibJkC-qqGw@mail.gmail.com>
 <ef15483d-5665-4da3-9b79-aefd3c725e1b@isocpp.org>
 <CAOHCbithEUfm+w_06V71=hpkqGUJvqiyDFqD7fesfgLy4uUieg@mail.gmail.com>
 <2c2b9360-8e5e-422d-9b85-124bd947b004@isocpp.org>
 <123b9f65-12fd-4285-bb6c-cfee383d4552@isocpp.org>
 <CAHOE3yeF6KBBz7a1uw58oA3Shh_w0HFGiLtUGEd4ntJAKBauew@mail.gmail.com>
 <CAA7U3HNDqV-j9wU0fw9kBwkoD6TiSmuZZhx1JCg3CNztYVMqqA@mail.gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_497_8406806.1359323337682"
X-Trace: ger.gmane.org 1359323347 8857 80.91.229.3 (27 Jan 2013 21:49:07 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 27 Jan 2013 21:49:07 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBSWBS2EAKGQESM6XYAQ@isocpp.org Sun Jan 27 22:49:27 2013
Return-path: <std-proposals+bncBCEKFTV6ZUMBBSWBS2EAKGQESM6XYAQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ia0-f200.google.com ([209.85.210.200])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBSWBS2EAKGQESM6XYAQ@isocpp.org>)
	id 1Tza6H-0004WT-Vi
	for gclcip-std-proposals@m.gmane.org; Sun, 27 Jan 2013 22:49:18 +0100
Original-Received: by mail-ia0-f200.google.com with SMTP id i38sf7273971iae.7
        for <gclcip-std-proposals@m.gmane.org>; Sun, 27 Jan 2013 13:48:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:x-beenthere:x-received:date:from:to:message-id
         :in-reply-to:references:subject:mime-version:x-original-sender
         :reply-to:precedence:mailing-list:list-id:x-google-group-id
         :list-post:list-help:list-archive:list-subscribe:list-unsubscribe
         :content-type;
        bh=l8T8KCtdUNWpWOY0aAZ0hy1nbwKWNAt2iFZY/b/9Mjo=;
        b=KCc++jJWMwRrd9gkdDm2VZB60fH2hf9teILDjD3dF+t06nv/EEkNmaTwMHkIrFST6o
         MAktuvbSWGHBJ1pZuv/BNFEeEGLNSLBs4BmCSGoWqhiuBaaw6XBvQtNxSEa4FeWt1jld
         8eyIKGzjPwnfSAV6yhBTXc7rA1IRYkx3c/QkluLVDpU0DtyvDAlqxVWrQx9Ce16o3N8h
         m6KYj7kyCC53G+/aNrz1SK9ZpevjuNdWto6r6mN0VrpBbgKkhPxOnCxa2GAVf+fb8mrX
         J4f3JaJuR9DmVOT/vEEcLFEnBomax/sas/ZkpWk9tCgWru8ncqpAeSIsoNMNoanIxUZR
         oHdg==
X-Received: by 10.42.144.198 with SMTP id c6mr8764667icv.22.1359323339258;
        Sun, 27 Jan 2013 13:48:59 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.178.72 with SMTP id cw8ls1403485igc.39.gmail; Sun, 27 Jan
 2013 13:48:58 -0800 (PST)
X-Received: by 10.50.150.180 with SMTP id uj20mr6253igb.7.1359323338601;
        Sun, 27 Jan 2013 13:48:58 -0800 (PST)
In-Reply-To: <CAA7U3HNDqV-j9wU0fw9kBwkoD6TiSmuZZhx1JCg3CNztYVMqqA@mail.gmail.com>
X-Original-Sender: jmckesson@gmail.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post?hl=en>,
 <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?hl=en&topic=25838>,
 <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe?hl=en>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:2370
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2370>

------=_Part_497_8406806.1359323337682
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, January 27, 2013 1:39:27 PM UTC-8, Olaf van der Spek wrote:
>
> On Sun, Jan 27, 2013 at 9:27 PM, Daniel James <dnl...@gmail.com<javascript:>> 
> wrote: 
> > But it could easily be changed to meet them. 'Optional' is a container 
> > (in the wider sense) with a maximum of 1 element. It is not in any 
> > sense a pointer. In fact, std::optional probably should meet the basic 
> > container requirements, as it would allow it to be used with generic 
> > functions. 
>
> It's a bit like static_vector with max_size 1, true. Though I'm not 
> sure what supporting a container interface really buys you. 
>
> >>  I think using operator* is natural. 
> > 
> > But it does currently imply certain semantics. The current situation 
> > is that if you write: 
> > 
> >     auto x = y; 
> >     *x = 2; 
> > 
> > Then for any standard type this is equivalent to assigning '2' to 
> > whatever y points to. By using 'operator*' in std::optional, the 
> > semantics of 'operator*' will be changed. That shouldn't be done 
> > lightly, especially since with templates and 'auto' a type is defined 
> > by the functions and operators that it supports.. 
>
> Isn't that more of a problem with the constructor than with operator*?


It's not a "problem" with the constructor. The constructor is doing exactly 
what it is supposed to. The problem is with the expectation that 
pointer-like things have reference semantics.

Optional is neither a container nor a pointer. It is its own type of thing, 
and it should have whatever is appropriate for users of that type. We don't 
want it to look too much like a pointer, lest users get the wrong idea. And 
we don't want it to look too much like a container, for the same reason.

-- 

--- 
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_497_8406806.1359323337682
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, January 27, 2013 1:39:27 PM UTC-8, Olaf van der Spek wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jan 27, 2013 at 9:2=
7 PM, Daniel James &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"FNRN7xMS6l0J">dnl...@gmail.com</a>&gt; wrote:
<br>&gt; But it could easily be changed to meet them. 'Optional' is a conta=
iner
<br>&gt; (in the wider sense) with a maximum of 1 element. It is not in any
<br>&gt; sense a pointer. In fact, std::optional probably should meet the b=
asic
<br>&gt; container requirements, as it would allow it to be used with gener=
ic
<br>&gt; functions.
<br>
<br>It's a bit like static_vector with max_size 1, true. Though I'm not
<br>sure what supporting a container interface really buys you.
<br>
<br>&gt;&gt; &nbsp;I think using operator* is natural.
<br>&gt;
<br>&gt; But it does currently imply certain semantics. The current situati=
on
<br>&gt; is that if you write:
<br>&gt;
<br>&gt; &nbsp; &nbsp; auto x =3D y;
<br>&gt; &nbsp; &nbsp; *x =3D 2;
<br>&gt;
<br>&gt; Then for any standard type this is equivalent to assigning '2' to
<br>&gt; whatever y points to. By using 'operator*' in std::optional, the
<br>&gt; semantics of 'operator*' will be changed. That shouldn't be done
<br>&gt; lightly, especially since with templates and 'auto' a type is defi=
ned
<br>&gt; by the functions and operators that it supports..
<br>
<br>Isn't that more of a problem with the constructor than with operator*?<=
/blockquote><div><br>It's not a "problem" with the constructor. The constru=
ctor is doing exactly what it is supposed to. The problem is with the expec=
tation that pointer-like things have reference semantics.<br><br>Optional i=
s neither a container nor a pointer. It is its own type of thing, and it sh=
ould have whatever is appropriate for users of that type. We don't want it =
to look too much like a pointer, lest users get the wrong idea. And we don'=
t want it to look too much like a container, for the same reason.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_497_8406806.1359323337682--

.