220 6134 <5226D6A4.4040707@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::degenerate<> class template : primitive/enum types with a special "undefined" value Date: Wed, 04 Sep 2013 08:43:48 +0200 Lines: 277 Approved: news@gmane.org Message-ID: <5226D6A4.4040707@wanadoo.fr> References: <18ab4801-260a-4228-8a7b-a71248b624e2@isocpp.org> <77a1bdf8-1e0d-4294-b528-d08ba5403c98@isocpp.org> <023111c2-c983-407d-918f-39be42aa2949@isocpp.org> <88ef15f1-6942-476e-b26c-6873ef6e6f0b@isocpp.org> <01900060-3aac-4645-a4a8-93b4e8760e42@isocpp.org> <5e63fe81-ab33-4bbb-ab4c-305f8b90140a@isocpp.org> <51a05a5a-ad56-4ffa-81d8-759953a93766@isocpp.org> <787f2f45-1fbc-4ce5-90fc-d8f0d8c2b8f4@isocpp.org> <6da8e8d3-7c26-4841-bc3f-40dd0715e92b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030009010302080107040501" X-Trace: ger.gmane.org 1378277031 27943 80.91.229.3 (4 Sep 2013 06:43:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2013 06:43:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBJVNTOIQKGQE47Y3RJI@isocpp.org Wed Sep 04 08:43:52 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VH6oi-00030f-FV for gclcip-std-proposals@m.gmane.org; Wed, 04 Sep 2013 08:43:52 +0200 Original-Received: by mail-wi0-f198.google.com with SMTP id hq15sf979246wib.9 for ; Tue, 03 Sep 2013 23:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=nGdRuJGIw8MUn1p1vEjJtXT3rw/1fmoj7l4KbJCGnnA=; b=OSLWftryI3Jt/1Rp4m6/hca1Rf1lhlRE5b6/0pHMADEWNqLmR1FwSTLo/lHOn8csHz bWLxAcgZJD/yZjjeGJXD8At6KzCESyFxOiRfdJ33TJMFL6JYWrMoC0rmYxmQqVldwREm A71ykUe1Daz3zIANeO8eF7jMiT1EuzOjMl/U6MaL1II6LK7kOST4zzBZIQ5OaFoJb0wJ skeodYaVJw37fqqJ4RFpdJtUv4O4JpmX5pM/oXgZHPeDtcsQslDGAAlp0vH8gyEqOO+1 w7BdDRbXYrWQ6MQPDGBFXMqh2FYvsQAbg34dTjPmegHipl+GO2gkXjJiHU93tBTRiVEM 3Uqg== X-Received: by 10.152.6.137 with SMTP id b9mr249834laa.4.1378277031370; Tue, 03 Sep 2013 23:43:51 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.8.131 with SMTP id r3ls366laa.52.gmail; Tue, 03 Sep 2013 23:43:50 -0700 (PDT) X-Received: by 10.152.37.41 with SMTP id v9mr1242772laj.9.1378277030374; Tue, 03 Sep 2013 23:43:50 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126]) by mx.google.com with ESMTP id ze5si9652224lbb.118.1969.12.31.16.00.00; Tue, 03 Sep 2013 23:43:50 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.126; Original-Received: from pc3.home ([2.10.128.70]) by mwinf5d59 with ME id Lujo1m0091XFuXW03ujpie; Wed, 04 Sep 2013 08:43:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: <6da8e8d3-7c26-4841-bc3f-40dd0715e92b@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.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:6134 Archived-At: This is a multi-part message in MIME format. --------------030009010302080107040501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 04/09/13 06:48, the.ultimate.koala@gmail.com a =E9crit : > Nicol Bolas, > > Thank you for your latest response, your opinion a lot clearer now. > > If I may reword your comments into short constructive suggestions,=20 > that would mean : > > * That the class is a worthwhile attempt at building something > standardizable, not a hack altogether. > > Just look at `optional`. All of that. > > * That I should more closely keep the "optional" interface. > > > ... yes. That's the point of the space optimized optional type. > It's exactly like `optional`, only certain values are > considered "not a real value". > > > I see no reason to give it a special name just because of that > /minor/ difference between them. > > * That the difference in behaviour is acceptable, and should be > proposed as another base template of optional<> instead of another > getting another name altogether. > > > Sure you can. It's quite simple: > > template > class optional > { > public: > constexpr optional() : t(NullValueProvider::getNullValue()) {} > constexpr optional(const T &_t) : t(_t) {} > constexpr optional(const nullopt_T &) : > t(NullValueProvider::getNullValue()) {} > > explicit operator bool() {return NullValueProvider::isNullValue(t);= } > > constexpr T const* operator->() const > { > return &t; //As with the regular optional version, the return > value is undefined if not engaged. > } > > constexpr const T &value() const > { > if(*this) return t; > throw bad_optional_access; //Throws when not engaged. > } > > private: > T t; > }; > > > > * That I should implement another base template using functors, to > accomodate values that are not allowed as non-type tempate arguments. > > What do you think about defining the degenerate class empty template struct degenerate { typedef T value_type; typedef DegenerateValue degenerate_value_type; }; and use it to make specialization of optional template struct optional > { // include here the degenerated specialization } In this way optional doesn't changes its interface (preserv only one=20 template parameter), and we are able to have optional and optional> Best, Vicente --=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/. --------------030009010302080107040501 Content-Type: text/html; charset=ISO-8859-1
Le 04/09/13 06:48, the.ultimate.koala@gmail.com a écrit :
Nicol Bolas,

Thank you for your latest response, your opinion a lot clearer now.

If I may reword your comments into short constructive suggestions, that would mean :
  • That the class is a worthwhile attempt at building something standardizable, not a hack altogether.
Just look at `optional`. All of that.
  • That I should more closely keep the "optional" interface.

... yes. That's the point of the space optimized optional type. It's exactly like `optional<T>`, only certain values are considered "not a real value".

I see no reason to give it a special name just because of that minor difference between them.
 
  • That the difference in behaviour is acceptable, and should be proposed as another base template of optional<> instead of another getting another name altogether.

Sure you can. It's quite simple:

template<typename T, typename NullValueProvider>
class optional
{
public:
  constexpr optional() : t(NullValueProvider::getNullValue()) {}
  constexpr optional(const T &_t) : t(_t) {}
  constexpr optional(const nullopt_T &) : t(NullValueProvider::getNullValue()) {}

  explicit operator bool() {return NullValueProvider::isNullValue(t);}

  constexpr T const* operator->() const
  {
    return &t; //As with the regular optional version, the return value is undefined if not engaged.
  }

  constexpr const T &value() const
  {
    if(*this) return t;
    throw bad_optional_access; //Throws when not engaged.
  }

private:
  T t;
};
<snip/>
  • That I should implement another base template using functors, to accomodate values that are not allowed as non-type tempate arguments.


What do you think about defining the degenerate class empty

template <typename T, typename DegenerateValue>
struct degenerate
{
  typedef T value_type;
  typedef DegenerateValue degenerate_value_type;
};

and use it to make  specialization of optional

template <typename T, typename DegenerateValue>
struct optional <degenerate<T,DegenerateValue>>
{
 // include here the degenerated specialization
}

In this way optional doesn't changes its interface (preserv only one template parameter), and we are able to have

optional<T>

and

optional<degenerate<Player, integral_constant<Player, Player(-1)>>

Best,
Vicente

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