220 2300 <0eea8a86-edef-4115-ac35-5f303bb77b45@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: Sat, 26 Jan 2013 04:54:53 -0800 (PST)
Lines: 162
Approved: news@gmane.org
Message-ID: <0eea8a86-edef-4115-ac35-5f303bb77b45@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>
 <4f505b21-669a-4ef0-95b9-edf9e5afa22d@isocpp.org>
 <36691ed8-3c44-4eb5-885f-27067fce7f40@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_769_9008552.1359204893136"
X-Trace: ger.gmane.org 1359204897 32050 80.91.229.3 (26 Jan 2013 12:54:57 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sat, 26 Jan 2013 12:54:57 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBH5ER6EAKGQEAMCBUYA@isocpp.org Sat Jan 26 13:55:17 2013
Return-path: <std-proposals+bncBCEKFTV6ZUMBBH5ER6EAKGQEAMCBUYA@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ia0-f198.google.com ([209.85.210.198])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBH5ER6EAKGQEAMCBUYA@isocpp.org>)
	id 1Tz5Hu-0006fp-4j
	for gclcip-std-proposals@m.gmane.org; Sat, 26 Jan 2013 13:55:14 +0100
Original-Received: by mail-ia0-f198.google.com with SMTP id h23sf3576141iae.9
        for <gclcip-std-proposals@m.gmane.org>; Sat, 26 Jan 2013 04:54:55 -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=gXnTiBbQl0fYYHydFfalUSX5s7EzOWXxJ81clOBlSFo=;
        b=dXt8alNxtqIm/pMLI/TQjVqtYKYvWU5DJaSfSW7Ntgmfsb472HIlBIRXhN8n040YL8
         gNwmjctucgZAsSRiXKCMPdBST2oAR5wLV8B9dj4f9MDRihMavBnSjF9qRS5lppIPavoe
         sN3laXrM1o/LxlZeFiUJWM8/9pU5ROUj/aW2oLsY3tdGf8BXsFUVcYU9baow1HyONTgY
         pV3rswQ7fFD8asUGjK+Ox2kuPOGhFXOY4pF9GsPsCFyZmulIdH7eA+au1kVgIIGlFYJ6
         IsGCPTunLU+hT+Fm0+u3MA82L5HdhhE+J4vPOavHoBNeS8pepzIoqCDJQlM3QrTOPdHe
         QpHg==
X-Received: by 10.50.191.195 with SMTP id ha3mr1564142igc.7.1359204895335;
        Sat, 26 Jan 2013 04:54:55 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.10.170 with SMTP id j10ls978965igb.28.gmail; Sat, 26 Jan
 2013 04:54:54 -0800 (PST)
X-Received: by 10.50.217.201 with SMTP id pa9mr336791igc.17.1359204894392;
        Sat, 26 Jan 2013 04:54:54 -0800 (PST)
In-Reply-To: <36691ed8-3c44-4eb5-885f-27067fce7f40@isocpp.org>
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:2300
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2300>

------=_Part_769_9008552.1359204893136
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir Batov wrote:
>
> On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:
>>
>> 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> wrote: 
>>> > ... 
>>> Do you think we should back away from all the pointer-ish interface 
>>> parts and move more towards container-ish?  
>>>
>>
> "We" are reading the 3rd revision of the document describing the facility 
> which has been in heavy use for a while and which has already been 
> submitted for standardization. "we should back away from all the 
> pointer-ish interface"... Is it a serious question or a tease?
>  
>  
>
>> 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?
>>
>
> Uhm, because we need to dereference 'optional' and the language has a 
> dereferencing operator (op*) which happens to be used everywhere else to 
> dereference.
>

That's called "assuming the conclusion" or "begging the question". The 
question in this case being whether `optional` should be thought of as 
being like a pointer. IE: that optional is a thing that can be dereferenced.

You don't dereference an optional any more than you dereference a 
std::vector. You only dereference *references* (it's right there in the 
name), and one of the most important aspects of optional is that it has *
value* semantics, not reference semantics. Optional is not a reference, so 
it doesn't make sense to use reference-like operations on it.

Dereferencing an optional makes no more sense than dereferencing an integer.

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.
>>
>
> There is nothing "pointer-ish" about the operator called a dereferencing 
> operator.
>

There is only one C++ type upon which applying uniary operator* results in 
guaranteed dereferencing. And those are pointers.

Pointers may not be the only things you can use uniary operator* on, but 
the user expectation of it is very clear: dereferencing a reference type. 
std::ref is a reference type. std::unique_ptr is a reference type.

std::optional is not.

Customization (oveloading) of that op* together with the other 
> dereferencing op->() is "important to a class of interesting programs" (as 
> Stroustrup puts it).
>

No, the ability to fetch the value from an optional is important. Exactly 
how you do that is dealer's choice.

-- 

--- 
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_769_9008552.1359204893136
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, January 26, 2013 2:09:36 AM UTC-8, Vladimir Batov wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, January 26, 201=
3 10:22:11 AM UTC+11, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">On Friday, January 25, 2013 2:09:20 PM UTC-8, Tony V E wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Jan 25, 2013 at 3:20 PM, Nicol Bolas=
 &lt;<a>jmck...@gmail.com</a>&gt; wrote:
<br>&gt; ...
<br>
Do you think we should back away from all the pointer-ish interface
<br>parts and move more towards container-ish?&nbsp; <br></blockquote></blo=
ckquote><div><br>"We" are reading the 3rd revision of the document describi=
ng the facility which has been in heavy use for a while and which has alrea=
dy been submitted for standardization. "we should back away from all the po=
inter-ish interface"...
Is it a serious question or a tease?<br>&nbsp;<br></div><div>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"></blockquote><div>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?<br=
></div></blockquote><div><br>Uhm, because we need to dereference 'optional'=
 and the language has a dereferencing operator (op*) which happens to be us=
ed everywhere else to dereference.<br></div></blockquote><div><br>That's ca=
lled "assuming the conclusion" or "begging the question". The question in t=
his case being whether `optional` should be thought of as being like a poin=
ter. IE: that optional is a thing that can be dereferenced.<br><br>You don'=
t dereference an optional any more than you dereference a std::vector. You =
only dereference <i>references</i> (it's right there in the name), and one =
of the most important aspects of optional is that it has <i>value</i> seman=
tics, not reference semantics. Optional is not a reference, so it doesn't m=
ake sense to use reference-like operations on it.<br><br>Dereferencing an o=
ptional makes no more sense than dereferencing an integer.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div>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.<br></div></blockquote><d=
iv><br>There is nothing "pointer-ish" about the operator called a dereferen=
cing operator.</div></blockquote><div><br>There is only one C++ type upon w=
hich applying uniary operator* results in guaranteed dereferencing. And tho=
se are pointers.<br><br>Pointers may not be the only things you can use uni=
ary operator* on, but the user expectation of it is very clear: dereferenci=
ng a reference type. std::ref is a reference type. std::unique_ptr is a ref=
erence type.<br><br>std::optional is not.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div>Customization (oveloading) of that op* togeth=
er with the other dereferencing op-&gt;() is "important to a class of inter=
esting programs" (as Stroustrup puts it).</div></blockquote><div><br>No, th=
e ability to fetch the value from an optional is important. Exactly how you=
 do that is dealer's choice.</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_769_9008552.1359204893136--

.