220 6115 <49b7008a-4ee7-40f2-9f5e-4975c367a75e@isocpp.org> article Path: news.gmane.org!not-for-mail From: the.ultimate.koala@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: std::degenerate<> class template : primitive/enum types with a special "undefined" value Date: Tue, 3 Sep 2013 07:28:01 -0700 (PDT) Lines: 171 Approved: news@gmane.org Message-ID: <49b7008a-4ee7-40f2-9f5e-4975c367a75e@isocpp.org> 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> <5225DB52.5060707@mail1.stofanet.dk> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2623_17569552.1378218481207" X-Trace: ger.gmane.org 1378218481 15090 80.91.229.3 (3 Sep 2013 14:28:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Sep 2013 14:28:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIODEPKWANBB4PDS6IQKGQEL3YD3OA@isocpp.org Tue Sep 03 16:28:04 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f71.google.com ([209.85.216.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VGraN-0005bF-5d for gclcip-std-proposals@m.gmane.org; Tue, 03 Sep 2013 16:28:03 +0200 Original-Received: by mail-qa0-f71.google.com with SMTP id hu16sf3394331qab.6 for ; Tue, 03 Sep 2013 07:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=Kl6rUGCKM6SMfPgteMLXkzs1M8C1SeRsoO9JY2AiSVg=; b=bSxO7DykdTm113ok4pfpkkKpcjknH2jLO+9elA/ErPaQTVlrxnyBrouBgLMPX/JEIM r3IoYnvs8QWTt4kQqqh1s8fqR/+aCH8sn2dZ0wiHbl21i5bx6OmkZkTRfjT6yvZvAvst v1oclhXXELY6ulCA6c6zXQnqo4ZpJAhTVCcQ9/B18EDpNC12u+PhvKSLkggfyuXgg7Vv 9YW/ngktBXtHR8knXl6cwvWDkD69z0gQLtiWpd0DNgORAyDIhLWMOOGE6SM62jIoTD/+ xgHN5F/jwB+TnvQIJRmLMk+kXdfA3JahDtVS/gVezYRako9GhfKooME/WU4Ax5W8Gny4 +r1g== X-Received: by 10.236.156.138 with SMTP id m10mr10499865yhk.26.1378218482273; Tue, 03 Sep 2013 07:28:02 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.29.129 with SMTP id k1ls2607442qeh.75.gmail; Tue, 03 Sep 2013 07:28:01 -0700 (PDT) X-Received: by 10.49.64.72 with SMTP id m8mr12123qes.20.1378218481582; Tue, 03 Sep 2013 07:28:01 -0700 (PDT) In-Reply-To: <5225DB52.5060707@mail1.stofanet.dk> X-Original-Sender: theultimatekoala@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:6115 Archived-At: ------=_Part_2623_17569552.1378218481207 Content-Type: text/plain; charset=ISO-8859-1 Bjorn, > Have you consider an extension where there are several "none" values? > > Yes. There are several problems. Let's call V the set of values of a type T : Choose a value v1 within V as the "none" value. The type degeneratewould be usable as a replacement for a hypothetical optional. Now choose a value v2 within V : - if it's the same as v1, then degenerate, v2> would degrade to degenerate. - if it's different of v1, then degenerate, v2> would be usable as a replacement for a hypothetical optional>. You can see that the count set of values is decrementing at every step. When you reach the empty set, what should happen? We could leave this to the programmer. To answer more precisely, it would suffice to accomodate class type with value semantics as type T. I think this can be done with functors. For instance, you may have a simple lexer/tokenizer that returns the > next token from the input. Let us say it recognizes integer, > floating-point numbers, and string. In addition to this, the tokenizer > may return special tokens to indicate errors or end-of-file. > > enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING }; > > So here we have two values that are set apart from the encodable set. > > In what order ? The most logical to me would be : enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING }; using possibly_erroneous_result_t = degenerate; using result_t = degeneratepossibly_erroneous_result_t { return possibly_erroneous_result_t{ Token::EOF }; }>; I did not yet try to write the variant accomodating classes with functors. -- --- 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/. ------=_Part_2623_17569552.1378218481207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bjorn,
Hav= e you consider an extension where there are several "none" values?


Yes. There are several problems. Let's call V the= set of values of a type T :

Choose a value v1 within V as the "none= " value. The type degen= erate<T, v1> would be usable as a replacement for a hypothetic= al optional<T - {v1}= >. Now choose a value v2 within V :
  • if it's the same a= s v1, then degenerate&l= t;degenerate<T, v1>, v2> would degrade to degenerate<T, v1>.
  • if it's different of v1, then degenerate<degenerate<T, v1>, v2> would be usable as a replacement for a hypotheti= cal optio= nal<optional<T - {v1,v2}>>.

You can see that the count set of val= ues is decrementing at every step. When you reach the empty set, what shoul= d happen? We could leave this to the programmer.

 To answer mor= e precisely, it would suffice to accomodate class type with value semantics= as type T. I think this can be done with functors.

For instance, you may have = a simple lexer/tokenizer that returns the
next token from the input. Let us say it recognizes integer,
floating-point numbers, and string. In addition to this, the tokenizer
may return special tokens to indicate errors or end-of-file.

   enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING };

So here we have two values that are set apart from the encodable set.


In what order ? The most logical to me would be :=

enum= class Token { ERROR, EOF= , INTEGER<= /span>, FLOAT, STRING };
using possibly_erroneous_result_t =3D degenerate<Token, Token::ERROR>;=
using result_t =3D degenerate<possibly_erroneous_result_t, constexpr []() -> possibly_erroneous_result_t  { return possibly_erroneous_result_t{ Token::EOF }; }>;
I did not yet try to write the variant accomodating classes with functors= ..

--
 
---
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-proposals/<= /a>.
------=_Part_2623_17569552.1378218481207-- .