220 2293 <36691ed8-3c44-4eb5-885f-27067fce7f40@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Vladimir Batov <vb.mail.247@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: optional<T>, one more value or two states
Date: Sat, 26 Jan 2013 02:09:36 -0800 (PST)
Lines: 120
Approved: news@gmane.org
Message-ID: <36691ed8-3c44-4eb5-885f-27067fce7f40@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>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_710_4639801.1359194976098"
X-Trace: ger.gmane.org 1359194977 19095 80.91.229.3 (26 Jan 2013 10:09:37 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sat, 26 Jan 2013 10:09:37 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCE7XWGGWIOBBYOWR2EAKGQEFEG2HDY@isocpp.org Sat Jan 26 11:09:56 2013
Return-path: <std-proposals+bncBCE7XWGGWIOBBYOWR2EAKGQEFEG2HDY@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-oa0-f71.google.com ([209.85.219.71])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCE7XWGGWIOBBYOWR2EAKGQEFEG2HDY@isocpp.org>)
	id 1Tz2hw-0004VK-CM
	for gclcip-std-proposals@m.gmane.org; Sat, 26 Jan 2013 11:09:56 +0100
Original-Received: by mail-oa0-f71.google.com with SMTP id n12sf7687388oag.10
        for <gclcip-std-proposals@m.gmane.org>; Sat, 26 Jan 2013 02:09:38 -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=1KNHV7QU9E2mnqkaLwMWvC6IKRLcXFrI+xnVVCnm8Ro=;
        b=oHvicGMY8lrz4YiiGzlsfL+6n/eV+Bl79+Wgsqg28rYKusoPbsMs9x2I/p9/0agYHj
         u9OmXZ0MatQ+HeAEGNlUE1YbtmSYel+GvQS2ZERq9RgvzO72HGxGnCdh6mPURKtLktLI
         RTYeKoVcGj9WOXtyYosoKWI3s0LSe6P0fD1QhnHlc4fkfJj1H3/FP6SFxBZKsPAYMCke
         vzWCmIYH01I3OykKbxO1gmnTplIHA/SDLsSlHOAF8InaKlZFxzCYqXr6FuXKkFClhA90
         hg5NwJYuKZAstEx2yNy142rvA3J8zAvUyaaVgD25kRqESlsD3cRYmJGKbSOXPDyZ05ui
         M7sg==
X-Received: by 10.42.158.1 with SMTP id f1mr6037053icx.6.1359194977948;
        Sat, 26 Jan 2013 02:09:37 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.153.195 with SMTP id vi3ls1019614igb.8.canary; Sat, 26 Jan
 2013 02:09:37 -0800 (PST)
X-Received: by 10.50.163.101 with SMTP id yh5mr284156igb.13.1359194977212;
        Sat, 26 Jan 2013 02:09:37 -0800 (PST)
In-Reply-To: <4f505b21-669a-4ef0-95b9-edf9e5afa22d@isocpp.org>
X-Original-Sender: vb.mail.247@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:2293
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2293>

------=_Part_710_4639801.1359194976098
Content-Type: text/plain; charset=ISO-8859-1

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.  
 

> 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. Customization (oveloading) of that op* together with the other 
dereferencing op->() is "important to a class of interesting programs" (as 
Stroustrup puts it). Indeed, that interface (as many other concepts) has 
been borrowed from C where these operators worked with pointers and C++ 
intentionally preserves C syntactic flavor. It does not make pointers claim 
"ownership" of these operators. These operators are the standard interface 
for the whole family of classes implementing the proxy concept/pattern... 
and the pointer is just one -- the most basic and primitive -- 
implementation of that concept. 
 

-- 

--- 
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_710_4639801.1359194976098
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, January 26, 2013 10:22:11 AM UTC+11, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Friday, January 25, 2013 2:09:20 P=
M UTC-8, Tony V E wrote:<blockquote class=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>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;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"></blockquote><div>No it should not. I'm not particularly enamoured =
with `operator*`, but `operator[]` makes no sense at all. Why not just `val=
ue` (or `get` for those who like that)? Do we really need an operator at al=
l?<br></div></blockquote><div><br>Uhm, because we need to dereference 'opti=
onal' and the language has a dereferencing operator (op*) which happens to =
be used everywhere else to dereference.&nbsp; <br>&nbsp;</div><blockquote c=
lass=3D"gmail_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 inter=
face"; there's only `operator*. That's the only part of optional that is li=
ke a pointer (OK, the `explicit operator bool` too, but that's hardly uniqu=
e to pointers); everything else works differently from pointers.<br></div><=
/blockquote><div><br>There is nothing "pointer-ish" about the operator call=
ed a dereferencing operator. Customization (oveloading) of that op* togethe=
r with the other dereferencing op-&gt;() is "important to a class of intere=
sting programs" (as Stroustrup puts it). Indeed, that interface (as many ot=
her concepts) has been borrowed from C where these operators worked with po=
inters and C++ intentionally preserves C syntactic flavor. It does not make=
 pointers claim "ownership" of these operators. These operators are the sta=
ndard interface for the whole family of classes implementing the proxy conc=
ept/pattern... and the pointer is just one -- the most basic and primitive =
-- implementation of that concept. <br>&nbsp;</div><br>

<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_710_4639801.1359194976098--

.
