220 2484 <d9f34ef0-9ff4-49e4-9662-de3977f505fa@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: Tue, 29 Jan 2013 03:30:54 -0800 (PST)
Lines: 124
Approved: news@gmane.org
Message-ID: <d9f34ef0-9ff4-49e4-9662-de3977f505fa@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>
 <CAHOE3yfsCHFTgcgSt+ytzqx_V5GRWrbobO5hSrd8nDQZ2NC98A@mail.gmail.com>
 <CAA7U3HMOQm09UYKJWCQmo34=su7LKeQyYu=2_P401CXSEE0k0A@mail.gmail.com>
 <CAHOE3yd5zt91JmmeAZyLiXxQLUNGQqatX5JRRGGbZVMg-0ckEQ@mail.gmail.com>
 <CAA7U3HNSp1MNvPzcD=9ssb0KSvrutWW2=jHQJknz2FhV4+bcww@mail.gmail.com>
 <CAHOE3ycx4fk=7S0PNcJ0tJsf_pN6ER2YZbF+E8t9n-wvxAGtsQ@mail.gmail.com>
 <7d4c0427-7818-41ea-bbb9-bf3e149c2882@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_291_10214938.1359459054222"
X-Trace: ger.gmane.org 1359459055 7877 80.91.229.3 (29 Jan 2013 11:30:55 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Tue, 29 Jan 2013 11:30:55 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBDT2DGOJ34DBB37FT2EAKGQE4J2YNHQ@isocpp.org Tue Jan 29 12:31:16 2013
Return-path: <std-proposals+bncBDT2DGOJ34DBB37FT2EAKGQE4J2YNHQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-qa0-f72.google.com ([209.85.216.72])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDT2DGOJ34DBB37FT2EAKGQE4J2YNHQ@isocpp.org>)
	id 1U09PF-0005O9-Pa
	for gclcip-std-proposals@m.gmane.org; Tue, 29 Jan 2013 12:31:14 +0100
Original-Received: by mail-qa0-f72.google.com with SMTP id l8sf705660qaq.11
        for <gclcip-std-proposals@m.gmane.org>; Tue, 29 Jan 2013 03:30: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=md8KfQJMzxZjFcmTHxU2bqjBcD0WHiu/fCbhILlQb4w=;
        b=QsL/hBgTfGOCH87z6MbiOQNmIZawdk7nyfCCr2lHeGtkdlwNAahCr7yyDrwr0PEm8j
         N1KnxlbJTf0Jd49syH17+Rwl2KIPv5EVc+MOzWTK7VG/E3P4rMjEp4I1Xq+snig8cs1/
         PyRWn+D8jcP0AUsGTI5dJXl9wYPojJrDgq/qktiIGzqbi6TZXupX8ojqqHktRjyKJVWK
         QHRjIrMLTLfsBhpSD5lMzuBcrL5HqS/NpT+J0rN/W6wwC689UvXbZBywBSzVvqcA1umf
         GjZCksRD+M6u7TR+t7kCaQnghE1h+zcr2UJZWqB8JZ0sF85PzIq/CU0DLauXRroS32p9
         Lnbw==
X-Received: by 10.236.139.105 with SMTP id b69mr268330yhj.31.1359459055392;
        Tue, 29 Jan 2013 03:30:55 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.49.127.142 with SMTP id ng14ls113870qeb.61.gmail; Tue, 29 Jan
 2013 03:30:54 -0800 (PST)
X-Received: by 10.49.84.167 with SMTP id a7mr38424qez.11.1359459054798;
        Tue, 29 Jan 2013 03:30:54 -0800 (PST)
In-Reply-To: <7d4c0427-7818-41ea-bbb9-bf3e149c2882@isocpp.org>
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:2484
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/2484>

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



W dniu wtorek, 29 stycznia 2013 11:18:02 UTC+1 u=BFytkownik Vincent Jacquet=
=20
napisa=B3:
>
> There is 2 ways to represent wether we have a value or not:
> - a container with 0 or 1 element
> - a pointer, either null or valid.
>
> The both have valid yet incompatible use cases, for instance:
> - the container-like representation for 0..1 could be promoted to 0..n=20
> - the pointer-like representation could be promoted to unique_ptr if the=
=20
> size of the object grows to the point where having unused memory space=20
> would be just a waste.
>
> If it doesn't make sense to have both representations in the same type=20
> (and I believe it doesn"t), I wouldn't  mind having two types with=20
> distinct, unambiguous definitions.
> I find the current definition of optional somewhat difficult to understan=
d=20
> as "optional" suggests 0 or 1, while it is defined as "a nullable type T=
=20
> that can store in its storage space either a value of type T or a special=
=20
> value nullopt". And, btw, if I understand the technical argument about "w=
hy=20
> not nullptr", I do not feel confortable about having a pointer like=20
> interface not capable to compare to nullptr.
>
=20
I agree with some of the observations, especially with the nullptr one.=20
However having two types for almost the same thing has a fundamental=20
problem.

Note that the primary purpose of optional<T> is to (1) answer the question=
=20
"do you have the value or not?" and if answer is "I have", (2) to give us=
=20
this value. Other aspects are secondary (although not unimportant). This is=
=20
why I say "two types for almost the same thing".

If we did this, some people would return one type from their functions,=20
some other people would be returning the other, and their code would be=20
incompatible (explicit conversion would not fix it, and it might add a=20
performance hit). For similar reasons, the deleter type of shared_ptr is=20
erased. The goal of the standard is to have one common interface for=20
everybody (rather than everyone coming with their own interface for almost=
=20
the same thing.)

--=20

---=20
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 e=
mail 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-proposa=
ls/?hl=3Den.



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

<br><br>W dniu wtorek, 29 stycznia 2013 11:18:02 UTC+1 u=BFytkownik Vincent=
 Jacquet napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>There =
is 2 ways to represent wether we have a value or not:</div><div>- a contain=
er with 0 or 1 element</div><div>- a pointer, either null or valid.</div><b=
r>The both have valid yet incompatible use cases, for instance:<div>- the c=
ontainer-like representation for 0..1 could be promoted to 0..n&nbsp;</div>=
<div>- the pointer-like representation could be promoted to unique_ptr if t=
he size of the object grows to the point where having unused memory space w=
ould be just a waste.<br></div><div><br></div><div>If it doesn't make sense=
 to have both representations in the same type (and I believe it doesn"t), =
I wouldn't &nbsp;mind having two types with distinct, unambiguous definitio=
ns.</div><div>I find the current definition of optional somewhat difficult =
to understand as "optional" suggests 0 or 1, while it is defined as "a null=
able type T that can store in its storage space either a value of type T or=
 a special value nullopt". And, btw, if I understand the technical argument=
 about "why not nullptr", I do not feel confortable about having a pointer =
like interface not capable to compare to nullptr.</div></blockquote><div>&n=
bsp;<br>I agree with some of the observations, especially with the nullptr =
one. However having two types for almost the same thing has a fundamental p=
roblem.<br><br>Note that the primary purpose of optional&lt;T&gt; is to (1)=
 answer the question "do you have the value or not?" and if answer is "I ha=
ve", (2) to give us this value. Other aspects are secondary (although not u=
nimportant). This is why I say "two types for almost the same thing".<br><b=
r>If we did this, some people would return one type from their functions, s=
ome other people would be returning the other, and their code would be inco=
mpatible (explicit conversion would not fix it, and it might add a performa=
nce hit). For similar reasons, the deleter type of shared_ptr is erased. Th=
e goal of the standard is to have one common interface for everybody (rathe=
r than everyone coming with their own interface for almost the same thing.)=
<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_291_10214938.1359459054222--

.