220 2284 <9a78cd61-e972-4dcb-8ea7-2dc377abc5a2@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: optional<T>, one more value or two states
Date: Fri, 25 Jan 2013 23:13:20 -0800 (PST)
Lines: 141
Approved: news@gmane.org
Message-ID: <9a78cd61-e972-4dcb-8ea7-2dc377abc5a2@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_718_13654870.1359184400406"
X-Trace: ger.gmane.org 1359184402 9534 80.91.229.3 (26 Jan 2013 07:13:22 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sat, 26 Jan 2013 07:13:22 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBDT2DGOJ34DBBE4ER2EAKGQE5AVMXII@isocpp.org Sat Jan 26 08:13:42 2013
Return-path: <std-proposals+bncBDT2DGOJ34DBBE4ER2EAKGQE5AVMXII@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-vb0-f69.google.com ([209.85.212.69])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDT2DGOJ34DBBE4ER2EAKGQE5AVMXII@isocpp.org>)
	id 1TyzxN-0002di-Go
	for gclcip-std-proposals@m.gmane.org; Sat, 26 Jan 2013 08:13:41 +0100
Original-Received: by mail-vb0-f69.google.com with SMTP id ff20sf1492773vbb.8
        for <gclcip-std-proposals@m.gmane.org>; Fri, 25 Jan 2013 23:13:23 -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=7XOwmgEV/5QJTpgKiWJLxv6m+oz+19vEadnQoVDnSL8=;
        b=Ue6I8eUE7DVBg6l+qGkH/UNUYzjN+9ZKVvzn0Hz82KHJgowRcnTuS/i6LIuDWEgAav
         1/IRjB9Tbttap2s7ddg3AOp7QjFcHbugnCNsdWgBn8bI5l0zzcvZjUlC3ksjrIyH8/07
         n9g+mdmDmghOZAYYwzADIaKv3igITVTZtIR4QwN+D1KwKfKllr/F1eZUvGfW6Qh0i3eM
         bjcz+r/STmXomkSI1f4Yx40o+tw8+6n15g0i2QYZTvc9ke4AEQbflQQm/V7CCdrcqQMW
         NVYGbc3zsFUjA+SGDrOBh4E0+xWbmXMuec61mkqY7fJPzeSdt9QfH+1DadEmEEBEx9J+
         gDkA==
X-Received: by 10.224.206.195 with SMTP id fv3mr868305qab.1.1359184403346;
        Fri, 25 Jan 2013 23:13:23 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.49.107.35 with SMTP id gz3ls508216qeb.52.gmail; Fri, 25 Jan
 2013 23:13:21 -0800 (PST)
X-Received: by 10.49.116.115 with SMTP id jv19mr1731541qeb.21.1359184401193;
        Fri, 25 Jan 2013 23:13:21 -0800 (PST)
In-Reply-To: <CAOHCbivJzdQbe22URgRuahCYYDPG8Ygsc4VG7f61zRBWXogekg@mail.gmail.com>
X-Original-Sender: akrzemi1@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:2284
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2284>

------=_Part_718_13654870.1359184400406
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu pi=B1tek, 25 stycznia 2013 23:09:20 UTC+1 u=BFytkownik Tony V E napi=
sa=B3:
>
> On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas <jmck...@gmail.com<javascrip=
t:>>=20
> wrote:=20
> >> And can be NULL.=20
> >=20
> >=20
> > No, it can be empty, not NULL. `optional` is a container.=20
> >=20
>
> Well, the container perspective is one way of looking at it, but not=20
> the only one.  Many people have called the concept NullableProxy, and=20
> C# calls their closely related thing Nullable<T>, and it converts to=20
> bool so that if (opt) works, whereas if (container) doesn't, and the=20
> empty optional constructor is called nullopt, not emptyopt,...=20
>
> Do you think we should back away from all the pointer-ish interface=20
> parts and move more towards container-ish?  Should *opt be opt[0]=20
> instead?  (I'm not being sarcastic, I've really been trying to find=20
> syntax that is more container-ish).=20
>
> I agree that it is not reference semantics, thus it is drastically=20
> different than pointers in a important, fundamental way, but it does=20
> share other semantics with pointers.  Or, I think equivalently,=20
> pointers share some semantics with containers.  The "empty or not"=20
> semantic.  Just not the ownership semantics.=20
>
> Is there a difference between empty and null?=20
>

These questions are really interesting. I do not want to answer them too=20
hastily. There is also one practical aspect that needs to be considered.=20
Regardless of what optional _is_, its primary use case (there are quite=20
many secondary use cases) is this: a function returns to you an optional=20
object (it owns the value). You *check if* there is a 'real' value, and if=
=20
so, consume it. The "check if" part is very important and frequent, so we=
=20
need to offer convenience here. The contextual conversion to bool works=20
very well with an if-statement, so I consider it a "must" in the interface.

"Check if there is a 'real' value, and if so, consume it." -- I guess this=
=20
is the essence of NullableProxy. You do not even need an explicit "null".=
=20
The way I see it, both pointers and optional model the concept. The former=
=20
do it with "shallow" copy/value semantics (or reference semantics), whereas=
=20
optional does it with deep copy/value semantics.=20

--=20

---=20
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@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_718_13654870.1359184400406
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br>W dniu pi=B1tek, 25 stycznia 2013 23:09:20 UTC+1 u=BFytkownik Tony =
V E napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 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"LNBoVr49mZEJ">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>
<br>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>These questions are really interesting. I do not =
want to answer them too hastily. There is also one practical aspect that ne=
eds to be considered. Regardless of what optional _is_, its primary use cas=
e (there are quite many secondary use cases) is this: a function returns to=
 you an optional object (it owns the value). You <b>check if</b> there is a=
 'real' value, and if so, consume it. The "check if" part is very important=
 and frequent, so we need to offer convenience here. The contextual convers=
ion to bool works very well with an if-statement, so I consider it a "must"=
 in the interface.<br><br>"Check if there is a 'real' value, and if so, con=
sume it." -- I guess this is the essence of NullableProxy. You do not even =
need an explicit "null". The way I see it, both pointers and optional model=
 the concept. The former do it with "shallow" copy/value semantics (or refe=
rence semantics), whereas optional does it with deep copy/value semantics. =
<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_718_13654870.1359184400406--

.