220 2479 <7d4c0427-7818-41ea-bbb9-bf3e149c2882@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 02:18:02 -0800 (PST) Lines: 144 Approved: news@gmane.org Message-ID: <7d4c0427-7818-41ea-bbb9-bf3e149c2882@isocpp.org> References:

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

Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1570_33137816.1359454682676" X-Trace: ger.gmane.org 1359454684 31764 80.91.229.3 (29 Jan 2013 10:18:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Jan 2013 10:18:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCMN7NOYVQEBBXGDT2EAKGQENJEMHYQ@isocpp.org Tue Jan 29 11:18:24 2013 Return-path: 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 ) id 1U08Gm-0007hh-6l for gclcip-std-proposals@m.gmane.org; Tue, 29 Jan 2013 11:18:24 +0100 Original-Received: by mail-qa0-f72.google.com with SMTP id l8sf619208qaq.7 for ; Tue, 29 Jan 2013 02:18:05 -0800 (PST) X-Received: by 10.224.72.199 with SMTP id n7mr341045qaj.5.1359454685419; Tue, 29 Jan 2013 02:18:05 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.119.3 with SMTP id kq3ls107531qeb.67.gmail; Tue, 29 Jan 2013 02:18:03 -0800 (PST) X-Received: by 10.49.12.97 with SMTP id x1mr30215qeb.25.1359454683003; Tue, 29 Jan 2013 02:18:03 -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:2479 Archived-At: ------=_Part_1570_33137816.1359454682676 Content-Type: text/plain; charset=ISO-8859-1 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 - the pointer-like representation could 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. 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 with distinct, unambiguous definitions. I find the current definition 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 confortable about having a pointer like interface not capable to compare to nullptr. Regards, Vincent On Monday, January 28, 2013 9:27:06 PM UTC+1, Daniel James wrote: > > On 28 January 2013 20:10, Olaf van der Spek > > wrote: > > On Mon, Jan 28, 2013 at 8:54 PM, Daniel James > > wrote: > >> On 28 January 2013 10:08, Olaf van der Spek > > wrote: > >>> On Mon, Jan 28, 2013 at 10:07 AM, Daniel James > > wrote: > >>>> > >>>> It depends on how well the range algorithms works out. They might > >>>> provide a more elegant way to manipulate optionals than if > statements, > >>>> similar to how a range algorithm can be more elegant than a for loop. > >>>> This has worked out well in other languages, for example in Scala: > >>> > >>> Wouldn't this be better handled by a wrapper that allows optionals, > >>> (smart) pointers and references to be handled as ranges? > >>> Separation of concerns says this shouldn't be handled by optional > itself. > >> > >> Fair enough. I find that such separation of concerns can end up with > >> unwieldy interfaces, but that's a matter of opinion. > > > > We can't add a range interface to raw pointers anyway, right? > > I don't want to add a range interface to raw pointers. > -- --- 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_1570_33137816.1359454682676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 val= id.

The both have valid yet incompatible use cases, for instance:<= div>- the container-like representation for 0..1 could be promoted to 0..n&= nbsp;

- the pointer-like representation could be promoted to uniq= ue_ptr if the size of the object grows to the point where having unused mem= ory space would be just a waste.

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 with distinct, unambiguou= s definitions.

I find the current definition 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 o= f type T or a special value nullopt". And, btw, if I understand the technic= al argument about "why not nullptr", I do not feel confortable about having= a pointer like interface not capable to compare to nullptr.

Regards,

Vincent

On Monday, January = 28, 2013 9:27:06 PM UTC+1, Daniel James wrote:

On 28 January 2013 20:10, Olaf van der Spek <olafv= ....@gmail.com> wrote:
> On Mon, Jan 28, 2013 at 8:54 PM, Daniel James <dnl...@gma= il.com> wrote:
>> On 28 January 2013 10:08, Olaf van der Spek <olafv...= @gmail.com> wrote:
>>> On Mon, Jan 28, 2013 at 10:07 AM, Daniel James <d= nl...@gmail.com> wrote:
>>>>
>>>> It depends on how well the range algorithms works out.= They might
>>>> provide a more elegant way to manipulate optionals tha= n if statements,
>>>> similar to how a range algorithm can be more elegant t= han a for loop.
>>>> This has worked out well in other languages, for examp= le in Scala:
>>>
>>> Wouldn't this be better handled by a wrapper that allows o= ptionals,
>>> (smart) pointers and references to be handled as ranges?
>>> Separation of concerns says this shouldn't be handled by o= ptional itself.
>>
>> Fair enough. I find that such separation of concerns can end u= p with
>> unwieldy interfaces, but that's a matter of opinion.
>
> We can't add a range interface to raw pointers anyway, right?

I don't want to add a range interface to raw pointers.

--

---
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_1570_33137816.1359454682676-- .