220 2511 <39dbba17-afca-4f23-b27e-2efc061ffbc6@isocpp.org> article Path: news.gmane.org!not-for-mail From: Vincent Jacquet Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: optional, one more value or two states Date: Tue, 29 Jan 2013 08:30:39 -0800 (PST) Lines: 152 Approved: news@gmane.org Message-ID: <39dbba17-afca-4f23-b27e-2efc061ffbc6@isocpp.org> References:

<2c2b9360-8e5e-422d-9b85-124bd947b004@isocpp.org> <123b9f65-12fd-4285-bb6c-cfee383d4552@isocpp.org>

<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_2508_20660289.1359477040002" X-Trace: ger.gmane.org 1359477043 18189 80.91.229.3 (29 Jan 2013 16:30:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Jan 2013 16:30:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMN7NOYVQEBBMXST6EAKGQEL5E3X6A@isocpp.org Tue Jan 29 17:31:03 2013 Return-path: 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 ) id 1U0E5N-0008KE-N0 for gclcip-std-proposals@m.gmane.org; Tue, 29 Jan 2013 17:31:02 +0100 Original-Received: by mail-oa0-f70.google.com with SMTP id n16sf3757863oag.1 for ; Tue, 29 Jan 2013 08:30:43 -0800 (PST) X-Received: by 10.42.87.198 with SMTP id z6mr1349685icl.27.1359477043128; Tue, 29 Jan 2013 08:30:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.53.173 with SMTP id c13ls376825igp.38.gmail; Tue, 29 Jan 2013 08:30:41 -0800 (PST) X-Received: by 10.50.187.133 with SMTP id fs5mr241804igc.12.1359477041537; Tue, 29 Jan 2013 08:30:41 -0800 (PST) In-Reply-To: X-Original-Sender: vjacquet@flowgroup.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:2511 Archived-At: ------=_Part_2508_20660289.1359477040002 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I agree, I simply wanted to investigate this possibility for the sake of=20 completness.=20 I find the definition of optional you gave above much clearer and=20 simpler than the one introducting your proposal. Also, interrestingly, it= =20 doesn't mention a nullable type anymore. Thanks, Vincent On Tuesday, January 29, 2013 12:30:54 PM UTC+1, Andrzej Krzemie=F1ski wrote= : > > > > W dniu wtorek, 29 stycznia 2013 11:18:02 UTC+1 u=BFytkownik Vincent Jacqu= et=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=20 >> understand as "optional" suggests 0 or 1, while it is defined as "a=20 >> nullable type T that can store in its storage space either a value of ty= pe=20 >> T or a special value nullopt". And, btw, if I understand the technical= =20 >> argument about "why not nullptr", I do not feel confortable about having= a=20 >> pointer like 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 is to (1) answer the questio= n=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 almos= t=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_2508_20660289.1359477040002 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I agree, I simply wanted to investigate this possibility for the sake of co= mpletness.

I find the definition of optional<T&= gt; you gave above much clearer and simpler than the one introducting your = proposal. Also, interrestingly, it doesn't mention a nullable type anymore.=

Thanks,

Vincent

On Tuesda= y, January 29, 2013 12:30:54 PM UTC+1, Andrzej Krzemie=F1ski wrote:

W dniu wtorek, 29 stycznia 201= 3 11:18:02 UTC+1 u=BFytkownik Vincent Jacquet napisa=B3:

There is 2 ways to represent wether we have a v= alue or not:
- a container with 0 or 1 element
- a poin= ter, either null or valid.

The both have valid yet incompatible us= e cases, for instance:
- the container-like representation for 0..1 cou= ld be promoted to 0..n
- the pointer-like representation co= uld be promoted to unique_ptr if the size of the object grows to the point = where having unused memory space would be just a waste.

<= /div>
If it doesn't make sense to have both representations in the same= type (and I believe it doesn"t), I wouldn't mind having two types wi= th distinct, unambiguous definitions.
I find the current definiti= on of optional somewhat difficult to understand as "optional" suggests 0 or= 1, while it is defined as "a nullable 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 c= onfortable about having a pointer like interface not capable to compare to = nullptr.

I agree with some of the observat= ions, especially with the nullptr one. However having two types for almost = the same thing has a fundamental problem.

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

If we did this, some people would retur= n one type from their functions, some other people would be returning the o= ther, and their code would be incompatible (explicit conversion would not f= ix it, and it might add a performance hit). For similar reasons, the delete= r type of shared_ptr is erased. The goal of the standard is to have one com= mon interface for everybody (rather than everyone coming with their own int= erface for almost the same thing.)

--

---
You received this message because you are subscribed to the Google Groups &= quot;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-pro= posals/?hl=3Den.

------=_Part_2508_20660289.1359477040002-- .