220 2764 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: optional references -- take 2 Date: Thu, 7 Feb 2013 00:12:35 -0800 (PST) Lines: 194 Approved: news@gmane.org Message-ID: References: <8d57e9e9-e4cc-441c-abeb-e6526531fad5@isocpp.org> <3534ECE0-D67E-443E-9593-76B644FDDF6A@gmail.com> <3aca8f41-7a21-40d8-9bf9-9c27dfa778f3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1604_16439068.1360224755557" X-Trace: ger.gmane.org 1360224757 25535 80.91.229.3 (7 Feb 2013 08:12:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Feb 2013 08:12:37 +0000 (UTC) Cc: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= , Sean Parent , sean.parent@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBB5GDZWEAKGQEHMIODOY@isocpp.org Thu Feb 07 09:12:57 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U3MbI-0003vs-4L for gclcip-std-proposals@m.gmane.org; Thu, 07 Feb 2013 09:12:56 +0100 Original-Received: by mail-ye0-f200.google.com with SMTP id r13sf2977044yen.3 for ; Thu, 07 Feb 2013 00:12:36 -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:cc: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=0qtYk20ySk0yiJTPPuUtrnCU/LHWKH5s2SVlUaNhcbY=; b=KotYUi+OPVfV/zhQzO6bcAbdkVFQBDXcqeG6ndGFIV0DZrvxcoftBwUj4g6HMwpqhV bvHbc3GO0kmqDvbgcNySuQEE628giiOJMTR8nHD/fZkMixOaBIUalMEcxRN3E/9waBN+ qo5cXoWltGwgqoxF7hndXPHrmrNHnVn7TaQMmv43fyNtUwmiV9fLdYulv07Gp6azOXU0 Q84qImd1pKzlnV5kfMkr1Q2KvewDzp7L+p6bgPpmfCregeBrSAvbmW4Ws2Tg0CtPWGbX 2AhtfO8gye8TOckuruxdlPL7ltQnQBJ2+i/RKS10ePgJvhKO3sewXN/nxOfzkCqTVDko /sAg== X-Received: by 10.224.176.196 with SMTP id bf4mr668997qab.4.1360224756524; Thu, 07 Feb 2013 00:12:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.82.112 with SMTP id h16ls695982qey.0.gmail; Thu, 07 Feb 2013 00:12:36 -0800 (PST) X-Received: by 10.49.58.140 with SMTP id r12mr23109qeq.35.1360224755950; Thu, 07 Feb 2013 00:12:35 -0800 (PST) In-Reply-To: <3aca8f41-7a21-40d8-9bf9-9c27dfa778f3@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: 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:2764 Archived-At: ------=_Part_1604_16439068.1360224755557 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu czwartek, 7 lutego 2013 03:40:11 UTC+1 u=BFytkownik Nicol Bolas=20 napisa=B3: > > > > On Wednesday, February 6, 2013 6:11:37 PM UTC-8, Sean Parent wrote: >> >> >> >> Sent from my iPad >> >> On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=F1ski = =20 >> wrote: >> >> >> > mixed assignment is illegal. Use one of the following instead:=20 >>> >=20 >>> > *oi =3D j; // if you want to alter the referred-to object=20 >>> > oi =3D {j}; // if you want to rebind a reference=20 >>> >=20 >>> >>=20 >>> >=20 >>> > Copy constructor and copy assignment are shallow: they only (re)bind = a=20 >>> > reference. Other operations are deep: this includes comparison (mixed= =20 >>> or=20 >>> > homogenous)=20 >>> >=20 >>> >>> Is optional a RegularType?=20 >>> >> >> I am not sure how to answer the question. Different people have slightly= =20 >> different expectations of a regular type. >> optional has: >> >> - default ctor >> - destructor >> - copy/move constructor (shallow) >> - copy/move assignment (shallow) >> - equality comparison (deep, provided that T is comparable) >> >> Then the answer would be no. The semantics of regular types are well=20 >> defined. See http://www.stepanovpapers.com/DeSt98.pdf. Copies must be=20 >> equal and disjoint. These semantics are not regular. I find it odd that= =20 >> copying would behave differently than a T& and I'm not sure what this=20 >> construct buys you over a T*. >> > > That's really the question I have about this whole `optional` thing:= =20 > what exactly is the use case for this functionality that `T*` can't also= =20 > cover? > =20 This question implies that optional references add no (or too little)=20 value. I agree with it to some extent. First, optional is a useful=20 addition to the standard even w/o optional references. Second, even if=20 optional references are useful, they are needed far less often.=20 What they buy you over raw pointers? 1. They make the ownership of the memory clear. When you get an optional= =20 reference, you are sure you are not responsible for deleting it. 2. They allow you too smoothly change the signature of your function=20 from taking T& to taking optional and you do not need to add=20 addressof() in all places where the function is called 3. They allow the usage of optional in "generic contexts". Personally, I do not find (3) convincing. But people often bring it up. One= =20 convincing use case, already mentioned in this thread is provided here:=20 https://groups.google.com/a/isocpp.org/d/msg/std-proposals/cXneqUj-5oo/zCnK= bHCGsxgJ Also, the "generic use" does not require optional references. One can=20 implement it oneself using a=20 trick described here:=20 http://kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html#rati= onale.refs Regarding (1) and (2), I happened to use optional reference in these=20 contexts and found them more elegant than pointers. But for these usages I= =20 never needed any kind of optional reference assignment. --=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_1604_16439068.1360224755557 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu czwartek, 7 lutego 2013 03:40:11 UTC+1 u=BFytkownik Nicol Bo= las napisa=B3:


On Wedne= sday, February 6, 2013 6:11:37 PM UTC-8, Sean Parent wrote:


Sent from my iPad

On Feb 5, 2013, at 12:02 PM, Andrzej Krzemie=F1ski <akrz.= ...@gmail.com> wrote:

> mixed assignment is illegal. = Use one of the following instead:
>
> *oi =3D j; // if you want to alter the referred-to object
> oi =3D {j}; // if you want to rebind a reference
>
>>
>
> Copy constructor and copy assignment are shallow: they only (re)bi= nd a
> reference. Other operations are deep: this includes comparison (mi= xed or
> homogenous)
>

Is optional<T&> a RegularType?

I am not sure how to answer the question. Differe= nt people have slightly different expectations of a regular type.
option= al<T&> has:
  • default ctor
  • destructor
    • copy/move constructor (shallow)
  • copy/move assignment (shallow)
  • equality comparison (deep, provided that T is comparable)
Then the answer would be no. The semantics of r= egular types are well defined. See http://www.stepanovpapers.com/DeSt= 98.pdf. Copies must be equal and disjoint. These semantics are not= regular. I find it odd that copying would behave differently than a T&= and I'm not sure what this construct buys you over a T*.

That's really the question I have about this whole `optiona= l<T&>` thing: what exactly is the use case for this functionality= that `T*` can't also cover?
 
This q= uestion implies that optional references add no (or too little) value. I ag= ree with it to some extent. First, optional<T> is a useful addition t= o the standard even w/o optional references. Second, even if optional refer= ences are useful, they are needed far less often.

What they buy you= over raw pointers?
  1. They make the ownership of the memory clear.= When you get an optional reference, you are sure you are not responsible f= or deleting it.
  2. They allow you too smoothly change the signature of= your function from taking T& to taking optional<T&> and you = do not need to add addressof() in all places where the function is called
  3. They allow the usage of optional in "generic contexts".

= Personally, I do not find (3) convincing. But people often bring it up. One= convincing use case, already mentioned in this thread is provided here: https://groups.google.com/a/isocp= p.org/d/msg/std-proposals/cXneqUj-5oo/zCnKbHCGsxgJ

Also= , the "generic use" does not require optional references. One can implement= it oneself using a
trick described here: http://kojot.sggw.waw.pl/~akr= zemi1/optional/tr2.optional.proposal.html#rationale.refs

Regarding (1= ) and (2), I happened to use optional reference in these contexts and found= them more elegant than pointers. But for these usages I never needed any k= ind of optional reference assignment.

--
 
---
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_1604_16439068.1360224755557-- .