220 2279 <4f505b21-669a-4ef0-95b9-edf9e5afa22d@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: Fri, 25 Jan 2013 15:22:11 -0800 (PST)
Lines: 150
Approved: news@gmane.org
Message-ID: <4f505b21-669a-4ef0-95b9-edf9e5afa22d@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>
 <CAOHCbivJzdQbe22URgRuahCYYDPG8Ygsc4VG7f61zRBWXogekg@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_265_32343032.1359156131821"
X-Trace: ger.gmane.org 1359156133 26291 80.91.229.3 (25 Jan 2013 23:22:13 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Fri, 25 Jan 2013 23:22:13 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJNHRSEAKGQECONA67Q@isocpp.org Sat Jan 26 00:22:33 2013
Return-path: <std-proposals+bncBCEKFTV6ZUMBBJNHRSEAKGQECONA67Q@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-oa0-f70.google.com ([209.85.219.70])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBJNHRSEAKGQECONA67Q@isocpp.org>)
	id 1TysbQ-0003ej-Rx
	for gclcip-std-proposals@m.gmane.org; Sat, 26 Jan 2013 00:22:33 +0100
Original-Received: by mail-oa0-f70.google.com with SMTP id j6sf5472584oag.5
        for <gclcip-std-proposals@m.gmane.org>; Fri, 25 Jan 2013 15:22:14 -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=qgZZiMH7ur2pAfWfYSPLVID3VWdKraqV9qJQw+eqt64=;
        b=NLNT+OHSFKs7KrJbBrGJY2RG0e+JX4m+JUegw24ehXsl+YO5ss0eswIdKFv6zqV4H+
         t6X5eiiL9wowwyZt4HEXApSlGO6CdHEJMBLpg1yMdS4YOH6f2zdnPDjK3psB71k5Yium
         Sr35/KzzdQFpwcWiF8EvPPrqhasvuLpQX73voApvxs8gQh6UyToOfw5OsJvzetJnEXIc
         VKU4sCJHO72LwNCA6tWOf6fznUD9cqUgMv//wlFiLX2lLbl//dKdqkrVK7O3+4Qn+FRO
         nFT/kfo/1JfMcMd+L9mpyQFP+SSNJr7b0O1Y91wuFI9fpENDC/+PjTQrE9s9XKWz930D
         1g8w==
X-Received: by 10.50.149.162 with SMTP id ub2mr100445igb.1.1359156133893;
        Fri, 25 Jan 2013 15:22:13 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.16.147 with SMTP id g19ls856820igd.19.canary; Fri, 25 Jan
 2013 15:22:13 -0800 (PST)
X-Received: by 10.50.13.225 with SMTP id k1mr45932igc.4.1359156132975;
        Fri, 25 Jan 2013 15:22:12 -0800 (PST)
In-Reply-To: <CAOHCbivJzdQbe22URgRuahCYYDPG8Ygsc4VG7f61zRBWXogekg@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:2279
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2279>

------=_Part_265_32343032.1359156131821
Content-Type: text/plain; charset=ISO-8859-1

On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:
>
> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com<javascript:>> 
> wrote: 
> >> And can be NULL. 
> > 
> > 
> > No, it can be empty, not NULL. `optional` is a container. 
> > 
>
> Well, the container perspective is one way of looking at it, but not 
> the only one.  Many people have called the concept NullableProxy, and 
> C# calls their closely related thing Nullable<T>, and it converts to 
> bool so that if (opt) works, whereas if (container) doesn't, and the 
> empty optional constructor is called nullopt, not emptyopt,... 
>
> Do you think we should back away from all the pointer-ish interface 
> parts and move more towards container-ish?  Should *opt be opt[0] 
> instead?  (I'm not being sarcastic, I've really been trying to find 
> syntax that is more container-ish).
>

No it should not. I'm not particularly enamoured with `operator*`, but 
`operator[]` makes no sense at all. Why not just `value` (or `get` for 
those who like that)? Do we really need an operator at all?

There is no "all the pointer-ish interface"; there's only `operator*`. 
That's the only part of optional that is like a pointer (OK, the `explicit 
operator bool` too, but that's hardly unique to pointers); everything else 
works differently from pointers.

These bikeshed issues are getting kinda out of control. The whole 
Nullable/NullableProxy/etc stuff to me seems to be overcomplicating what is 
really a very simple discussion. I need to return a value or return 
nothing, and the user needs to be able to detect this. I want that thing I 
return to have value semantics. End of story.

If people want to come along later and adapt the interface for some generic 
`NullableProxy` concept, feel free. But the interface we use for optional 
should be doing what we need optional to do. No more, no less. The concept 
can adapt the interface as needed.

I agree that it is not reference semantics, thus it is drastically 
> different than pointers in a important, fundamental way, but it does 
> share other semantics with pointers.  Or, I think equivalently, 
> pointers share some semantics with containers.  The "empty or not" 
> semantic.  Just not the ownership semantics. 
>
> Is there a difference between empty and null?
>

Yes: `optional<T*>` exists. Such an object has 3 possible states: the 
optional could be empty. The optional could contain a valid pointer. Or the 
optional could contain *nullptr*.

That's why we should not consider them the same. To me, "null" means "a 
pointer which has no value and cannot be derefenced". If you say that an 
`optional<T*>` is "null", my assumption is that you're talking about what 
is stored within the optional and not the state of the optional itself.

-- 

--- 
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/?hl=en.



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

On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas=
 &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"LNB=
oVr49mZEJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; And can be NULL.
<br>&gt;
<br>&gt;
<br>&gt; No, it can be empty, not NULL. `optional` is a container.
<br>&gt;
<br>
<br>Well, the container perspective is one way of looking at it, but not
<br>the only one. &nbsp;Many people have called the concept NullableProxy, =
and
<br>C# calls their closely related thing Nullable&lt;T&gt;, and it converts=
 to
<br>bool so that if (opt) works, whereas if (container) doesn't, and the
<br>empty optional constructor is called nullopt, not emptyopt,...
<br>
<br>Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish? &nbsp;Should *opt be opt[0]
<br>instead? &nbsp;(I'm not being sarcastic, I've really been trying to fin=
d
<br>syntax that is more container-ish).<br></blockquote><div><br>No it shou=
ld not. I'm not particularly enamoured with `operator*`, but `operator[]` m=
akes no sense at all. Why not just `value` (or `get` for those who like tha=
t)? Do we really need an operator at all?<br><br>There is no "all the point=
er-ish interface"; there's only `operator*`. That's the only part of option=
al that is like a pointer (OK, the `explicit operator bool` too, but that's=
 hardly unique to pointers); everything else works differently from pointer=
s.<br><br>These bikeshed issues are getting kinda out of control. The whole=
 Nullable/NullableProxy/etc stuff to me seems to be overcomplicating what i=
s really a very simple discussion. I need to return a value or return nothi=
ng, and the user needs to be able to detect this. I want that thing I retur=
n to have value semantics. End of story.<br><br>If people want to come alon=
g later and adapt the interface for some generic `NullableProxy` concept, f=
eel free. But the interface we use for optional should be doing what we nee=
d optional to do. No more, no less. The concept can adapt the interface as =
needed.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
I agree that it is not reference semantics, thus it is drastically
<br>different than pointers in a important, fundamental way, but it does
<br>share other semantics with pointers. &nbsp;Or, I think equivalently,
<br>pointers share some semantics with containers. &nbsp;The "empty or not"
<br>semantic. &nbsp;Just not the ownership semantics.
<br>
<br>Is there a difference between empty and null?<br></blockquote><div><br>=
Yes: `optional&lt;T*&gt;` exists. Such an object has 3 possible states: the=
 optional could be empty. The optional could contain a valid pointer. Or th=
e optional could contain <i>nullptr</i>.<br><br>That's why we should not co=
nsider them the same. To me, "null" means "a pointer which has no value and=
 cannot be derefenced". If you say that an `optional&lt;T*&gt;` is "null", =
my assumption is that you're talking about what is stored within the option=
al and not the state of the optional itself.<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 unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.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_265_32343032.1359156131821--

.