220 18859 <07A8C4E9-69D7-4EE2-AADB-7179FB93BEA1@gmail.com> article Path: news.gmane.org!not-for-mail From: Vitali Lovich Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Compressing std::optional Date: Sun, 28 Jun 2015 09:19:51 -0700 Lines: 259 Approved: news@gmane.org Message-ID: <07A8C4E9-69D7-4EE2-AADB-7179FB93BEA1@gmail.com> References: <4359ebfb-5e20-42c1-84a0-16ef6201db33@isocpp.org> <33303ec4-d4c3-4080-a7bb-346496e38114@isocpp.org> <749546C6-8165-4775-A3E2-319F6EA84EE5@gmail.com> <8fc1d9f9-41a8-431c-a89d-448bea95a5db@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1435508405 2843 80.91.229.3 (28 Jun 2015 16:20:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 16:20:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCFIZX46Q4HRBLV5YCWAKGQERZU4JII@isocpp.org Sun Jun 28 18:20:00 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z9FJH-0008Bl-Rc for gclcip-std-proposals@m.gmane.org; Sun, 28 Jun 2015 18:20:00 +0200 Original-Received: by oibr82 with SMTP id r82sf251776795oib.1 for ; Sun, 28 Jun 2015 09:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:in-reply-to:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=2cDPf68e0pvWQEjT4CF+KqUhejKWCAMbR+Uo2vDh3tE=; b=WNj/I/c1OZrsNP0FvMoe9LBzkt+ceBdCaLywrf4o589QF2v+3Hk9lCov+o5+9IEojC U266Fsg9R9VySUax9z+JUWXZBw7lLIkQfi/xHcC1EiEITIq9cppI9aRjw158kjmtkAv4 dvWCVo5Vw4g40nDVWeOjQ88HH9nUpkK91HeyfTUDtSdGfQdjvucf35I/q3ZWDtXoAGpp C9hWRkhAnK+Wvrbhh4iFz/IjeScaIM9bYakC4h1RahVF8MQKgVLdcIfN/tgAAXMm/HF7 jCLIzfK3dDjmfY+SQu+4bq7IUSdVaVWDkt6dTXc6NXyOvel/h2CY044yRlHQ2b4r54B/ X-Gm-Message-State: ALoCoQmjT8kMvv8+PEYnN7zGIuziwIiOATfy1ICaXONbWlczDW+V1mdvH4FsFfKgW90RTN8nw3Iv X-Received: by 10.43.160.202 with SMTP id md10mr15759385icc.19.1435508398826; Sun, 28 Jun 2015 09:19:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.16.81 with SMTP id y78ls1517694ioi.57.gmail; Sun, 28 Jun 2015 09:19:58 -0700 (PDT) X-Received: by 10.68.57.206 with SMTP id k14mr3374227pbq.97.1435508398258; Sun, 28 Jun 2015 09:19:58 -0700 (PDT) Original-Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com. [2607:f8b0:400e:c03::230]) by mx.google.com with ESMTPS id oe9si60031724pbc.247.2015.06.28.09.19.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jun 2015 09:19:58 -0700 (PDT) Received-SPF: pass (google.com: domain of vlovich@gmail.com designates 2607:f8b0:400e:c03::230 as permitted sender) client-ip=2607:f8b0:400e:c03::230; Original-Received: by padev16 with SMTP id ev16so92738638pad.0 for ; Sun, 28 Jun 2015 09:19:58 -0700 (PDT) X-Received: by 10.70.109.199 with SMTP id hu7mr23597958pdb.71.1435508397941; Sun, 28 Jun 2015 09:19:57 -0700 (PDT) Original-Received: from [10.0.0.5] (c-67-180-190-206.hsd1.ca.comcast.net. [67.180.190.206]) by mx.google.com with ESMTPSA id gc5sm39413499pbb.53.2015.06.28.09.19.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jun 2015 09:19:56 -0700 (PDT) In-Reply-To: X-Mailer: iPhone Mail (13A290) X-Original-Sender: vlovich@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of vlovich@gmail.com designates 2607:f8b0:400e:c03::230 as permitted sender) smtp.mail=vlovich@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: 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:18859 Archived-At: --Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > On Jun 28, 2015, at 7:38 AM, David Krauss wrote: >=20 >=20 >> On 2015=E2=80=9306=E2=80=9328, at 3:47 AM, vlovich@gmail.com wrote: >>=20 >> Hey David, I really like the idea of a basic_optional a lot better & can= provide a better foundation for doing something like compressing the optio= nal state for many optionals into a bit-field (e.g. protobuf) which is one = the problems left unsolved. >> I also like the idea of encapsulating the sentinel'ness as you propose (= e.g. std::optional>) instead of having a separate t= raits. Can you elaborate a bit on how this could be accomplished? Right n= ow optional has a boolean >> field. My original design moved that boolean field into the policy/trai= ts & used the empty base-class optimization to get rid of it when unnecessa= ry. In the std::optional> example, would never_qui= et_nan have a static constexpr member >> boolean that said "I understand how to read/write my state from the valu= e"? Or would there be an ADL traits class that parametrized this? >=20 > I=E2=80=99m thinking like this: >=20 > // Thin wrapper: >=20 > template< typename float_t > > struct never_quiet_nan { > float_t value =3D 0; >=20 > operator float_t & () { return value; } > operator float_t const & () const { return value; } > }; >=20 > // ADL object representation functions: >=20 > template< typename float_t > > void invalidate_representation( never_quiet_nan< float_t > * invalid_ptr = ) > { * reinterpret_cast< float_t * >( invalid_ptr ) =3D std::numeric_lim= its< float_t >::quiet_NaN; } >=20 > template< typename float_t > > bool is_valid_representation( never_quiet_nan< float_t > const * question= able_ptr ) > { return std::isnan( * reinterpret_cast< float_t const * >( questiona= ble_ptr ) ); } Hmmm... And how would optional decide what state it needs to store? >> The std::vector & polymorphism cases I think are less compelling for as-= if as I can't imagine a use-case where you would store either in optional. = std::vector has a natural empty state & using optional> seems mo= re likely to be a poor design >> than anything else.=20 >=20 > One use-case of std::optional is for output parameters. Those are already= an anti-pattern per se, but still I think a blanket statement that optiona= l should never happen is too strong. >=20 > Under as-if, it=E2=80=99s a question of how many priorities a standard li= brary can implement before they need to freeze their ABI. >=20 >> Polymorphic classes tend to be prone to slicing when used as a value-typ= e. optional for enum classes (enums too?) would be possible if there were = reflection so that you could query for an out-of-range value to use as a se= ntinel. >=20 > Just ask the user for invalidate_representation and is_valid_representati= on. Enumerations aren=E2=80=99t closed so reflection can=E2=80=99t really d= iscover invalid values. >=20 >> As you say, an implementation would be free to optimize these if it felt= important under the as-if rule so there would be no need to specify it in = the proposal. >>=20 >> I was hoping to get to writing up the proposal this weekend but it looks= like probably it will end up next weekend. If you have any more thoughts = on the matter feel free to email me directly. >=20 > My hands are full=E2=80=A6 I=E2=80=99m procrastinating here already :P . >=20 > Good luck! >=20 > --=20 >=20 > ---=20 > You received this message because you are subscribed to a topic in the Go= ogle Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.= org/d/topic/std-proposals/46J1onhWJ-s/unsubscribe. > To unsubscribe from this group and all its topics, send an email to std-p= roposals+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-propo= sals/. --=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/. --Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On J= un 28, 2015, at 7:38 AM, David Krauss <potswa@mac.com> wrote:

=
On 20= 15=E2=80=9306=E2=80=9328, at 3:47 AM, vlovich@gmail.com wrote:

He= y David, I really like the idea of a basic_optional a lot better & can = provide a better foundation for doing something like compressing the option= al state for many optionals into a bit-field (e.g. protobuf) which is one t= he problems left unsolved.
I also like the idea of encapsulat= ing the sentinel'ness as you propose (e.g. std::optional<never_quiet_nan= <double>>) instead of having a separate traits.  Can you elab= orate a bit on how this could be accomplished?  Right now optional has= a boolean
field.  My original design moved that boolean= field into the policy/traits & used the empty base-class optimization = to get rid of it when unnecessary.  In the std::optional<never_quie= t_nan<double>> example, would never_quiet_nan have a static conste= xpr member
boolean that said "I understand how to read/write = my state from the value"?  Or would there be an ADL traits class that = parametrized this?

I=E2=80=99m thinking like this:

// Thin wrapper:
=
template< typename float_t >=
struct never_quiet_nan = {
    float_t = value =3D 0;

    ope= rator float_t & () { return value; }
    operator float_t const & () const { return va= lue; }
};

<= /font>
// ADL object= representation functions:

template< typename float_t >
void invalidate_representation( never_quiet_nan< float_t &= gt; * invalid_ptr )
    { * reinterpret_cast< float_t * >( invalid_ptr ) =3D std::numeric_limits< flo= at_t >::quiet_NaN; }

template< typename float_t >
bool is_valid_representation( never_quiet_nan< float_t &= gt; const * questionable_ptr = )
    { return std::isnan( * reinterpret_cast<&n= bsp;float_t<= font face=3D"Courier" class=3D""> const * >( questionable_ptr&= nbsp;) ); }
Hmmm... And how w= ould optional decide what state it needs to store?

The std::vector &am= p; polymorphism cases I think are less compelling for as-if as I can't imag= ine a use-case where you would store either in optional.  std::vector = has a natural empty state & using optional<vector<X>> seems= more likely to be a poor design
than anything else. 

One use-case of std::optional is = for output parameters. Those are already an anti-pattern per se, but still = I think a blanket statement that optional= <vector> should never happen is too strong.

Under as-if, it=E2=80=99s a questio= n of how many priorities a standard library can implement before they need = to freeze their ABI.

Polymorph= ic classes tend to be prone to slicing when used as a value-type.  opt= ional for enum classes (enums too?) would be possible if there were reflect= ion so that you could query for an out-of-range value to use as a sentinel.=

Just ask the user for i= nvalidate_representation and is_va= lid_representation. Enumerations aren=E2=80=99t closed so reflection= can=E2=80=99t really discover invalid values.

As you say, an implementation would be free to optimize th= ese if it felt important under the as-if rule so there would be no need to = specify it in the proposal.

I was hoping to ge= t to writing up the proposal this weekend but it looks like probably it wil= l end up next weekend.  If you have any more thoughts on the matter fe= el free to email me directly.
=
My hands are full=E2=80=A6 I=E2=80=99m procr= astinating here already :P .

Good luck!

--

---
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.= google.com/a/isocpp.org/d/topic/std-proposals/46J1onhWJ-s/unsubscribe.<= br> To unsubscribe from this group and all its topics, 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/<= /a>.

--

---
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>.
--Apple-Mail-1951A2E4-13C5-493F-9A54-81594CA59B73-- .