220 15835 <CAOHCbis81AdVq8sMnPEqhV0UNWpc1ThNTpgGgUHb_OEAE9QM6w@mail.gmail.com> article
Path: news.gmane.org!not-for-mail
From: Tony V E <tvaneerd@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: RFC: Adding Coherency Between any and optional<T>
Date: Sat, 24 Jan 2015 23:09:49 -0500
Lines: 171
Approved: news@gmane.org
Message-ID: <CAOHCbis81AdVq8sMnPEqhV0UNWpc1ThNTpgGgUHb_OEAE9QM6w@mail.gmail.com>
References: <54C36998.3070600@wanadoo.fr>
	<54C3EF58.8050707@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a11c26986669e1c050d7231b3
X-Trace: ger.gmane.org 1422158995 9085 80.91.229.3 (25 Jan 2015 04:09:55 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sun, 25 Jan 2015 04:09:55 +0000 (UTC)
To: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <std-proposals@isocpp.org>
Original-X-From: std-proposals+bncBCUZ5QWKNQII5WMRUYCRUBFEKHW3A@isocpp.org Sun Jan 25 05:09:54 2015
Return-path: <std-proposals+bncBCUZ5QWKNQII5WMRUYCRUBFEKHW3A@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-ee0-f70.google.com ([74.125.83.70])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCUZ5QWKNQII5WMRUYCRUBFEKHW3A@isocpp.org>)
	id 1YFEWG-0006ns-Ra
	for gclcip-std-proposals@m.gmane.org; Sun, 25 Jan 2015 05:09:52 +0100
Original-Received: by mail-ee0-f70.google.com with SMTP id c13sf1670585eek.1
        for <gclcip-std-proposals@m.gmane.org>; Sat, 24 Jan 2015 20:09:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:content-type:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:list-post:list-help:list-archive:list-subscribe
         :list-unsubscribe;
        bh=digIzAnS2ANwgiGw5hpRDfxiVZRZ/aD9EhRGg3GIndU=;
        b=QQ3pK4yrFGQuxXjMuLL5e18/MJI/rd9C57hKW+XHnMWiCSiugbIQAzgHWdv7NOdDhe
         /t209fZKZoSkHrhj+3d9azIXeG8rHM1fhA1qOU54iYEB2VgelcFT08VD4ZGgD013dwEL
         w3sTw9MPLpoF/uQTnLBacjYiZCRXM0MVarEdHTL4qdZW8G9dtExFultFoadP2d1Lkcwf
         yKv9gMilO7m6XHgvyPnugSwKjVXlEDWwxQJwDZnDpiwRWfBctInPraeSuJXv706EQxYB
         4vdmzXwGrsfvReXo6VumMGmD4ss9x6g2a0PHJfnNbll6bJKTqFo+j6XWdWk9L25Q8OKe
         gKug==
X-Gm-Message-State: ALoCoQnBYqDNwkIAsMphyFL6YOI0Qjxft6TfNt5n2LVK/ETJQsYeqIZLX0ID4z1Cm3QnqcX0U0qz
X-Received: by 10.112.137.70 with SMTP id qg6mr536329lbb.14.1422158992337;
        Sat, 24 Jan 2015 20:09:52 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.152.42.234 with SMTP id r10ls345301lal.17.gmail; Sat, 24 Jan
 2015 20:09:50 -0800 (PST)
X-Received: by 10.152.115.212 with SMTP id jq20mr15040163lab.36.1422158990187;
        Sat, 24 Jan 2015 20:09:50 -0800 (PST)
Original-Received: from mail-la0-x232.google.com (mail-la0-x232.google.com. [2a00:1450:4010:c03::232])
        by mx.google.com with ESMTPS id ku8si5607467lac.24.2015.01.24.20.09.50
        for <std-proposals@isocpp.org>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Sat, 24 Jan 2015 20:09:50 -0800 (PST)
Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::232 as permitted sender) client-ip=2a00:1450:4010:c03::232;
Original-Received: by mail-la0-f50.google.com with SMTP id hs14so3222047lab.9
        for <std-proposals@isocpp.org>; Sat, 24 Jan 2015 20:09:50 -0800 (PST)
X-Received: by 10.112.172.167 with SMTP id bd7mr15122081lbc.14.1422158989793;
 Sat, 24 Jan 2015 20:09:49 -0800 (PST)
Original-Received: by 10.112.89.41 with HTTP; Sat, 24 Jan 2015 20:09:49 -0800 (PST)
In-Reply-To: <54C3EF58.8050707@gmail.com>
X-Original-Sender: tvaneerd@gmail.com
X-Original-Authentication-Results: mx.google.com;       spf=pass (google.com:
 domain of tvaneerd@gmail.com designates 2a00:1450:4010:c03::232 as permitted
 sender) smtp.mail=tvaneerd@gmail.com;       dkim=pass header.i=@gmail.com;
       dmarc=pass (p=NONE dis=NONE) header.from=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>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15835
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/15835>

--001a11c26986669e1c050d7231b3
Content-Type: text/plain; charset=UTF-8

On Sat, Jan 24, 2015 at 2:15 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

>  Here are some observations:
>
>    - Do we need the distinction between nullopt_t and none_t? Can't we
>    use none_t/none as a universal tag type to specify "nothing" in the
>    standard library and replace nullopt_t with none_t in the draft?
>
>
In the optional<> discussions, we discussed this, and decided to make
nullopt_t specific to optional (and not use nullptr_t or create a
std::none_t, etc) for a few reasons:

- "better safe than sorry" - we didn't want to tackle more than just
optional.  A generic none_t would get used by users in user-defined types
in who knows what ways.

- we wanted optional<X> opx = nullopt to be clear.  If it was optional<X>
opx = none and X took none_t in its constructor, you wouldn't know whether
the programmer meant an empty optional, or a engaged optional holding an
X(none). (ie consider optional<any>).  Currently we still have that exact
problem with optional<optional<T>> but hopefully that happens less often.

A library-wide none_t could be useful, but the more useful it is, the more
likely it is to introduce ambiguities (either does-not-compile ambiguities,
or "I'm not sure if that's what they expected" ambiguities").

I _think_ a none_t with *consistent* usage (ie either none_t is always
assigned to the inner-most type, or none_t is always assigned to the
outer-most type, but pick one rule and never break it) could be useful.
But it would take some thought, and we didn't want to have that stopping
optional from proceeding. (Although we slowed down optional for other
reasons anyhow....)


>
>    - You introduce the type<T> tag to specify the type to be forward
>    constructed in any::any(type<T>, in_place_t, ...) but chose to use
>    any::emplace<T>() instead. Wouldn't it be more consistent to go with
>    any::emplace(type<T>, ...) as well? I get that you can't specify the
>    template argument in the constructor and thus need the tag type which is
>    not the case for ordinary member functions. However I can't recall the last
>    time I had to specify a template argument in the member function of a
>    standard library type...
>
>
could we make both work? (Maybe that would be too complicated/tricky and/or
just not worth it)

>
>    -
>    - Does any::any(type<T>, in_place_t, ...) require the in_place_t
>    argument? When passing in type<T> you already state the intent of
>    constructing an instance of type T, which can only be done by forwarding
>    all other arguments to its constructor. As far as I can see there is no
>    remaining ambiguity.
>
>
I haven't read the proposal yet, but that makes sense to me.


>
>    -
>
> Miro
>


Tony

-- 

--- 
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/.

--001a11c26986669e1c050d7231b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jan 24, 2015 at 2:15 PM, Miro Knejp <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Here are some observations:<br>
    <ul>
      <li>Do we need the distinction between nullopt_t and none_t? Can&#39;=
t
        we use none_t/none as a universal tag type to specify &quot;nothing=
&quot;
        in the standard library and replace nullopt_t with none_t in the
        draft?</li></ul></div></blockquote><div><br></div><div>In the optio=
nal&lt;&gt; discussions, we discussed this, and decided to make nullopt_t s=
pecific to optional (and not use nullptr_t or create a std::none_t, etc) fo=
r a few reasons:<br><br></div><div>- &quot;better safe than sorry&quot; - w=
e didn&#39;t want to tackle more than just optional.=C2=A0 A generic none_t=
 would get used by users in user-defined types in who knows what ways.<br><=
br></div><div>- we wanted optional&lt;X&gt; opx =3D nullopt to be clear.=C2=
=A0 If it was optional&lt;X&gt; opx =3D none and X took none_t in its const=
ructor, you wouldn&#39;t know whether the programmer meant an empty optiona=
l, or a engaged optional holding an X(none). (ie consider optional&lt;any&g=
t;).=C2=A0 Currently we still have that exact problem with optional&lt;opti=
onal&lt;T&gt;&gt; but hopefully that happens less often.<br><br></div><div>=
A library-wide none_t could be useful, but the more useful it is, the more =
likely it is to introduce ambiguities (either does-not-compile ambiguities,=
 or &quot;I&#39;m not sure if that&#39;s what they expected&quot; ambiguiti=
es&quot;).<br><br></div><div>I _think_ a none_t with *consistent* usage (ie=
 either none_t is always assigned to the inner-most type, or none_t is alwa=
ys assigned to the outer-most type, but pick one rule and never break it) c=
ould be useful.=C2=A0 But it would take some thought, and we didn&#39;t wan=
t to have that stopping optional from proceeding. (Although we slowed down =
optional for other reasons anyhow....)<br></div><div>=C2=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><ul>
      <li>You introduce the type&lt;T&gt; tag to specify the type to be
        forward constructed in any::any(type&lt;T&gt;, in_place_t, ...)
        but chose to use any::emplace&lt;T&gt;() instead. Wouldn&#39;t it b=
e
        more consistent to go with any::emplace(type&lt;T&gt;, ...) as
        well? I get that you can&#39;t specify the template argument in the
        constructor and thus need the tag type which is not the case for
        ordinary member functions. However I can&#39;t recall the last time
        I had to specify a template argument in the member function of a
        standard library type...<br></li></ul></div></blockquote><div><br><=
/div><div>could we make both work? (Maybe that would be too complicated/tri=
cky and/or just not worth it) <br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 bgcolor=3D"#FFFFFF" text=3D"#000000"><ul><li>
      </li>
      <li>Does any::any(type&lt;T&gt;, in_place_t, ...) require the
        in_place_t argument? When passing in type&lt;T&gt; you already
        state the intent of constructing an instance of type T, which
        can only be done by forwarding all other arguments to its
        constructor. As far as I can see there is no remaining ambiguity.<b=
r></li></ul></div></blockquote><div><br></div><div>I haven&#39;t read the p=
roposal yet, but that makes sense to me.<br>=C2=A0<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><ul><li>
      </li>
    </ul>
    Miro<br></div></blockquote><div>=C2=A0</div><div><br></div><div>Tony<br=
></div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c26986669e1c050d7231b3--

.