220 18794 <20bac98b-87e8-4a49-b11d-4c5c8d19d351@isocpp.org> article Path: news.gmane.org!not-for-mail From: vlovich@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Compressing std::optional Date: Thu, 25 Jun 2015 15:18:48 -0700 (PDT) Lines: 410 Approved: news@gmane.org Message-ID: <20bac98b-87e8-4a49-b11d-4c5c8d19d351@isocpp.org> References: <4359ebfb-5e20-42c1-84a0-16ef6201db33@isocpp.org> <922bcabe-6e9e-4fea-9e62-4fdd124e29e0@isocpp.org> <75a9dccd-8f7a-4f08-818c-cfaa19566950@isocpp.org> <335755d7-ab1c-4a61-b794-89f6d14a22d4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1403_1405183621.1435270728420" X-Trace: ger.gmane.org 1435270734 29785 80.91.229.3 (25 Jun 2015 22:18:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 22:18:54 +0000 (UTC) Cc: vlovich@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCFIZX46Q4HRBSP4WGWAKGQEXBSSBTA@isocpp.org Fri Jun 26 00:18:52 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z8FTv-0000eu-MV for gclcip-std-proposals@m.gmane.org; Fri, 26 Jun 2015 00:18:52 +0200 Original-Received: by obbjt1 with SMTP id jt1sf22637542obb.3 for ; Thu, 25 Jun 2015 15:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=aD2n52duZUY/o2UzY7nwHcYZr3SkzVCYvy7vUtYuIv0=; b=etXAtD+AzztS8mVxodl8Bf1YySwd5imEopMVE1uZIK+QnNI7rV5wI8jR921G9PY8EX Wc1i0/+j1gaMwjDwkffh0UuM9Pk6ulaKPujVADobeenwG2isRQ1EHqUtrbRT2R7qVoKS Z+M+xbqHJ4FVHPGs/fbqaVBaXWL0xmYQXOF3Eio4TtcXuadOHP+dJ0O6lQ5BBA4Jrism T3SCJhKxekHS82y6VeEzyusOfSYv/FZ2NYdphoPJFlUqJxmucp9HNW8rctT3wuQp0hqj agnH6vTy51+MeWNGlSOdj3DXAJgjLTHjM9gNSMzYXrilnFHC6kTaW2+JGh3cdInlgIe6 6BjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=aD2n52duZUY/o2UzY7nwHcYZr3SkzVCYvy7vUtYuIv0=; b=ONYcyH5wHerRRB2Dk5S+PAsyodS+jD3B6vqwGST5XiYvoLjOGISsRKiB0Q3GoQeADz tTwzQOVmECq7Wem9zsnCzZLGxwpnE88a+bgMiOyU67aoT0a7nNX5fEKrAcU4/DEMvdcm oR9gpfC43j5iBvzOXQUEOmhWSBSXRWgsAhUNNT9MwCIrWxh3haTkB1pAGGOsOHRUUg5h 5XT5QgoGVZZSR8j4AJfodj7btAtS9juFGNKph13SphmjUIjtLqJKtwBJwaF1asSVDsuk 2vq2y4MOOCyUt9O1Kybhr07HTYVd+Nz9DPDOpWPf1KHILOJ8b2WktxS2QbJk55KBsOO/ tJWg== X-Gm-Message-State: ALoCoQkB7AXOIpsirY+UZGxmSgMz7pyYiWbWpO7S8boTU9SoEjsWYJZWmtYgeyW2kvClOjGVodq1 X-Received: by 10.50.78.131 with SMTP id b3mr6547624igx.1.1435270730489; Thu, 25 Jun 2015 15:18:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.80.8 with SMTP id n8ls2181056igx.17.canary; Thu, 25 Jun 2015 15:18:49 -0700 (PDT) X-Received: by 10.50.61.195 with SMTP id s3mr141653igr.10.1435270729717; Thu, 25 Jun 2015 15:18:49 -0700 (PDT) In-Reply-To: <335755d7-ab1c-4a61-b794-89f6d14a22d4@isocpp.org> X-Original-Sender: vlovich@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:18794 Archived-At: ------=_Part_1403_1405183621.1435270728420 Content-Type: multipart/alternative; boundary="----=_Part_1404_1043452088.1435270728420" ------=_Part_1404_1043452088.1435270728420 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, June 25, 2015 at 2:54:06 PM UTC-7, vlo...@gmail.com wrote: > > > > On Thursday, June 25, 2015 at 12:59:58 PM UTC-7, Nevin ":-)" Liber wrote: >> >> On 25 June 2015 at 14:22, wrote: >> >>> >>> >>> On Thursday, June 25, 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrot= e: >>>> >>>> On 25 June 2015 at 12:58, wrote: >>>> >>>>> I=E2=80=99m not as familiar with the issues so I=E2=80=99m probably m= isunderstanding=20 >>>>> your concern. Is it that every custom specialization of optional mus= t be=20 >>>>> able to no-throw construct the disengaged state? >>>>> >>>> >>>> No, but you weren't proposing to specialize optional. You were=20 >>>> proposing to add a second policy-like template parameter to optional. = =20 >>>> Those are two very different things. >>>> >>>> If you are specializing it, I really have to question why it has to be= =20 >>>> spelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic= =20 >>>> constructs (which is the main reason to have them spelled the same way= ). =20 >>>> Shades of vector all over again... >>>> >>> Well to get an optimized policy, the user would have to specialize it= =20 >>> with their user-defined policy object. Is that not the right terminolo= gy? >>> >> >> vector is a specialization of vector, and has a different interfac= e=20 >> than vector. That is very different than, say, providing an allocator= =20 >> (which is basically a policy) to a vector. >> =20 >> >>> In any case what I meant to say is that does every possible policy=20 >>> need to meet these criteria?=20 >>> >> >> It is in the interface for optional, so either it does or you change the= =20 >> interface. You get to explore the design space. >> =20 >> >>> The disengaged state is smaller than every state of T, in both=20 >>>> homogeneous (optional vs optional) and heterogeneous (optional vs=20 >>>> T) comparisons. Do you intend for that to hold, in which case compari= ng=20 >>>> two engaged optionals now behaves differently than comparing the value= s=20 >>>> they hold. >>>> >>> I'm probably being a little thick. Can you clarify with the following= =20 >>> implementation of equality where you would see a problem with the=20 >>> implementation? >>> >>> bool operator=3D=3D(const optional& lhs, const optional& = rhs) >>> { >>> if (!lhs.is_initialized() ^ rhs.is_initialized()) { >>> return false; >>> } >>> >>> if (lhs.is_initialized() && rhs.is_initialized()) { >>> return *lhs =3D=3D *rhs; >>> } >>> >>> return true; >>> } >>> >>> >> Say you use NaN for your disengaged value. >> >> float f =3D std::numeric_limits::quiet_NaN(); >> assert(!(f=3D=3Df)); >> assert(!(optional(f) =3D=3D optional(f))); // fails >> > This is actually still true. I'm assuming you meant if you include a=20 > policy where it's folded into the nan: > assert (!(optional(f) =3D=3D optional nan_sentinel>(f))); // fails because both are disengaged as per the polic= y > assert (!(optional(f) =3D=3D optional(f))); /= /=20 > fails because lhs is disengaged. > > assert(!(optional(f) =3D=3D f)); // fails >> > This still passes. However: > assert (!(optional(f) =3D=3D f))) // fails because lh= s is=20 > disengaged. > Oh. I misread this. So actually in the current implementation I=20 prototyped (https://github.com/vlovich/Optional), this would still hold. The problem is that disengaged is false & so disengaged !=3D "engaged". =20 However, for consistency this should actually be true. I need to fix the= =20 comparison operators to understand comparison against a sentinel. If NaN is a valid value, then you either need to find a different sentinel= =20 > or realize that an optimized policy won't work for you. > > assert(!(f =3D=3D optional(f))); // fails >> >> Now, I'm perfectly willing (although others on the committee are not) to= =20 >> say that non-regular types such as float are insane, and equality=20 >> comparisons aren't a problem for regular types. >> >> However, ordered comparisons are different. Using string("Geronimo") as= =20 >> the disengaged value: >> >> string s =3D "Geronimo"; >> string t =3D "Geronim"; >> >> assert(t < s); >> assert(optional(t) < optional(s)); // fails >> assert(optional(t) < s); // fails >> assert(t < optional(s)); // fails >> >> Is that the desired behavior? As part of your proposal, you explore the= =20 >> design space, pick something, and then LEWG will debate it if they reall= y=20 >> want the feature. >> > Yes it is. The sentinel value is defined to be the disengaged state &=20 > cannot be represented as a valid value. If the above assertions are=20 > unexpected then the policy > is incorrectly implemented. > =20 > >> I have nothing against coming to Kona. I would certainly be interested= =20 >>> in presenting it but I can also work to get champions too. I haven't e= ven=20 >>> presented a draft of a proposal so perhaps discussing Kona is a bit=20 >>> premature? >>> For all I know there are intractable problems that come up when I flush= =20 >>> it out fully. >>> >> >> My general advice is that people attend a meeting or two before making a= =20 >> proposal, so that can see what they are in for. Roughly speaking, it's= =20 >> like defending a dissertation in front of a panel of people who don't=20 >> really care if you graduate. You are the domain expert fielding tough= =20 >> questions from other (domain and non-domain) experts, as well as from=20 >> people like me. >> >> I do realize that it sometimes takes a proposal to get an employer to=20 >> send someone to a meeting, in which case I advise not picking something = too=20 >> ambitious. IMO, this is a very ambitious proposal. Of course, other=20 >> committee members may feel otherwise and be willing to put in the=20 >> preparatory effort so that it gets a fair chance. We are all volunteers= =20 >> and speak only for ourselves or those we represent, as no one speaks for= =20 >> the committee. >> --=20 >> Nevin ":-)" Liber (847) 691-1404 >> =20 > --=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/. ------=_Part_1404_1043452088.1435270728420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, June 25, 2015 at 2:54:06 PM UTC-7, vlo...@gmail.com wr= ote:


On Thursday, June = 25, 2015 at 12:59:58 PM UTC-7, Nevin ":-)" Liber wrote:
On 25 = June 2015 at 14:22, <vlo...@gmail= ..com> wrote:


On Thursday, June 25= , 2015 at 11:54:07 AM UTC-7, Nevin ":-)" Liber wrote:
On 25 June 2015 at 12:58,= <vlo...@gmail.com>= wrote:
I=E2=80=99m not as famili= ar with the issues so I=E2=80=99m probably misunderstanding your concern.  Is it that every custom specialization of optional mus= t=20 be able to no-throw construct the disengaged state?

No, but you weren't proposing to specialize optional.&= nbsp; You were proposing to add a second policy-like template parameter to = optional.  Those are two very different things.

If you are specializing it, I really have to question why it has to be s= pelled o-p-t-i-o-n-a-l, as it really isn't substitutable in generic constru= cts (which is the main reason to have them spelled the same way).  Sha= des of vector<bool> all over again...
Well to get an optimized policy, the user would have to sp= ecialize it with their user-defined policy object.  Is that not the ri= ght terminology?

vector<bool> i= s a specialization of vector, and has a different interface than vector.&nb= sp; That is very different than, say, providing an allocator (which is basi= cally a policy) to a vector.
 
&n= bsp; In any case what I meant to say is that does every possible policy nee= d to meet these criteria? 

It is= in the interface for optional, so either it does or you change the interfa= ce.  You get to explore the design space.
 
The disengaged state is smaller than every state of T, in both= homogeneous (optional<T> vs optional<T>) and heterogeneous (op= tional<T> vs T) comparisons.  Do you intend for that to hold, in= which case comparing two engaged optionals now behaves differently than co= mparing the values they hold.
I'm probably being a little thick.  Can you clarify with the follow= ing implementation of equality where you would see a problem with the imple= mentation?

bool operator=3D=3D(const optional<T, P1>& lhs, const<= span style=3D"color:rgb(0,0,0)"> optional<T, P2>& rhs)
= {
    if (!lhs.is_initialized() ^ rhs.is_init= ialized()) {
        return= false;
   = }

    = if (lhs.is_initi= alized() && rhs.is_initialized()) {
        return *lhs =3D=3D *rhs;
    }

=     return true<= /span>;
}


Say you use NaN for your disengaged value.
<= br>
float f =3D std::numeric_limits<float>::quiet_NaN(= );
assert(!(f=3D=3Df));
assert(!(optional<f= loat>(f) =3D=3D optional<float>(f))); // fails
This is actually still true.  I'm assuming= you meant if you include a policy where it's folded into the nan:
asser= t (!(optional<float, nan_sentinel>(f) =3D=3D optional<float, nan_s= entinel>(f))); // fails because both are disengaged as per the policyassert (!(optional<float, nan_sentinel>(f) =3D=3D optional<float&= gt;(f))); // fails because lhs is disengaged.

assert(!(optional<float>(f) =3D=3D f)); // fails
This still passes.  Howe= ver:
assert (!(optional<float, nan_seninel>(f) =3D=3D f))) // fail= s because lhs is disengaged.
Oh.  I misread= this.  So actually in the current implementation I prototyped (https://github.com/vlovich/Optional), this would still hold.
= The problem is that disengaged is false & so disengaged !=3D "engaged".=   However, for consistency this should actually be true.  I need = to fix the comparison operators
to understand comparison against a senti= nel.

If NaN = is a valid value, then you either need to find a different sentinel or real= ize that an optimized policy won't work for you.

assert(!(f =3D=3D optional<float>(f))); // fails

Now, I'm perfectly willing (although others on the co= mmittee are not) to say that non-regular types such as float are insane, an= d equality comparisons aren't a problem for regular types.

However, ordered comparisons are different.  Using string("Ge= ronimo") as the disengaged value:

string s =3D "Ge= ronimo";
string t =3D "Geronim";

assert(= t < s);
assert(optional<string>(t) < optional<stri= ng>(s)); // fails
assert(optional<string>(t) < s); //= fails
assert(t < optional<string>(s)); // fails

Is that the desired behavior?  As part of your propo= sal, you explore the design space, pick something, and then LEWG will debat= e it if they really want the feature.
<= div>Yes it is.  The sentinel value is defined to be the disengaged sta= te & cannot be represented as a valid value.  If the above asserti= ons are unexpected then the policy
is incorrectly implemented.
 =
I have nothing against coming= to Kona.  I would certainly be interested in presenting it but I can = also work to get champions too.  I haven't even presented a draft of a= proposal so perhaps discussing Kona is a bit premature?
For all I know = there are intractable problems that come up when I flush it out fully.
<= /div>

My general advice is that people atte= nd a meeting or two before making a proposal, so that can see what they are= in for.  Roughly speaking, it's like defending a dissertation in fron= t of a panel of people who don't really care if you graduate.  You are= the domain expert fielding tough questions from other (domain and non-doma= in) experts, as well as from people like me.

I do = realize that it sometimes takes a proposal to get an employer to send someo= ne to a meeting, in which case I advise not picking something too ambitious= ..  IMO, this is a very ambitious proposal.  Of course, other comm= ittee members may feel otherwise and be willing to put in the preparatory e= ffort so that it gets a fair chance.  We are all volunteers and speak = only for ourselves or those we represent, as no one speaks for the committe= e.
--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

--

---
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-proposa= ls+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/<= /a>.
------=_Part_1404_1043452088.1435270728420-- ------=_Part_1403_1405183621.1435270728420-- .