220 9977 article Path: news.gmane.org!not-for-mail From: Matheus Izvekov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Explicitly-defaulted enumeration operators Date: Wed, 19 Mar 2014 15:14:00 -0700 (PDT) Lines: 179 Approved: news@gmane.org Message-ID: References: <3B09C97E-7ADE-49ED-8C31-B5B41CD3DDE7@gmail.com> <781009e3-cd3c-4cb8-b034-b51a7c97c750@isocpp.org> <10450602-fee9-48c4-9fa2-d000e434f5fb@isocpp.org> <6F532E62-C10A-404A-8F0D-662B7EA3D202@gmail.com> <24e85eaf-e67b-4a0b-acee-47d996d6f6ee@isocpp.org> <7F327393-B9EF-46EB-A40E-86F80EFEF5BD@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_62_5262444.1395267240238" X-Trace: ger.gmane.org 1395459611 24650 80.91.229.3 (22 Mar 2014 03:40:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 03:40:11 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCOKZ27XTMNRBIUMWSMQKGQERZBRBWI@isocpp.org Sat Mar 22 04:40:21 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WRCnE-0007Iq-M9 for gclcip-std-proposals@m.gmane.org; Sat, 22 Mar 2014 04:40:20 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id wn1sf12125263obc.9 for ; Fri, 21 Mar 2014 20:40:19 -0700 (PDT) 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:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=QfgWCXQP3dY6E61V26LullgwH3V7oemJT7UE3sq0Q0Y=; b=LZ7muO5WRHKcMt8rznB4s1wOgXA3Z1pA+Rv1nCRJGc7Cedx0+BpyPlHT1VV/wwoR9x YpDE7WlDg//rap35DTY0laZvR4tekHQTEtjglVavOtFfOcGcM3CFBpyjzyZF181Rho9L OQZMkuEHRHKrUQKqHP1F1+hs86YuXLI/jqGFI8YLdNnmMW3qojTtWswhR13pmAJL+C/x ZAzXYGA7AuRTZZwfJml9j5hZ/IYHWL8NgRnGHjBXUJm4hLzjZksC6RyECrLlRy41rxRA pD5ezDnWYGriCCiZWAaJcp5LyifigVuGpngBnStjIOQ8Fo1dowsboDTXNJnH9ya48VbJ OHtw== X-Gm-Message-State: ALoCoQnqL6zThaMqvu3cc1hDKWIH5gtr2G8JqnTDOycxzUMPisDWBBqTNCya+XHvsm3j04qXZ8SB X-Received: by 10.182.51.200 with SMTP id m8mr7616132obo.16.1395459619636; Fri, 21 Mar 2014 20:40:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.89.136 with SMTP id v8ls873656qgd.17.gmail; Fri, 21 Mar 2014 20:40:18 -0700 (PDT) X-Received: by 10.236.197.39 with SMTP id s27mr11170754yhn.36.1395459618731; Fri, 21 Mar 2014 20:40:18 -0700 (PDT) Original-Received: by 10.50.46.229 with SMTP id y5msigm; Wed, 19 Mar 2014 15:14:01 -0700 (PDT) X-Received: by 10.182.28.70 with SMTP id z6mr41990obg.16.1395267241024; Wed, 19 Mar 2014 15:14:01 -0700 (PDT) In-Reply-To: X-Original-Sender: mizvekov@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:9977 Archived-At: ------=_Part_62_5262444.1395267240238 Content-Type: text/plain; charset=UTF-8 On Wednesday, March 19, 2014 2:48:31 PM UTC-3, Matthew Woehlke wrote: > > > That would be awesome. In fact I have a 'to do' to suggest exactly this. > > std::flags might cover that specific use case, but I also want to be > able to do things like: > > enum class foo { > ...values... > foo(std::string const*); // constructor > operator std::string(); // conversion operator > }; > > (These sorts of conversions already show up frequently, but right now > must be implemented as free functions; the ability to make them members > would be great.) > > > But now that really starts to diverge from Walter's proposal. It seems he did leave out member functions/operators on purpose. If you want to leverage his work, it seems the best option would be to have a non-member form of the cast operator, and also replace the constructor with that. Something like: enum class foo { ...values...; operator std::string(const foo &); // conversion to string operator operator foo(const std::string &); // conversion from string operator }; Something else I would really love to see though is using an enumeration > as an underlying ("base") type of an enumeration, e.g.: > > enum class A { a1, a2, ... }; > enum class B : A { b1, b2, ... }; > > B bb = B::a1; // legal; a1, etc. are in scope of B, inherited from A > > But would then be implicit conversions from A allowed? B bb = A::a1; I would suggest not, because this behavior would need to be a special case. Also, what would be the underlying_type_t of B? Would it be A or int? If it could be A, that could be surprising for a lot of code. It would also not play well with Thiago Macieira's idea of multiple inheritance. At the same type, it would be interesting to have type_traits to query the hierarchy of such enums. How to implement that then? Specialize std::is_base_of? -- --- 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_62_5262444.1395267240238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, March 19, 2014 2:48:31 PM UTC-3, Matthew Woe= hlke wrote:

That would be awesome. In fact I have a 'to do' to suggest exactly this.

std::flags might cover that specific use case, but I also want to be=20
able to do things like:

   enum class foo {
     ...values...
     foo(std::string const*); // constructor
     operator std::string(); // conversion operator
   };

(These sorts of conversions already show up frequently, but right now= =20
must be implemented as free functions; the ability to make them members= =20
would be great.)


 
But now that really starts to diverge from = Walter's proposal.
It seems he did leave out member functions/operators = on purpose.
If you want to leverage his work, it seems the best option w= ould be to have
a non-member form of the cast operator, and also replace= the constructor with that.
Something like:
enum class foo {
     ...values...;

=      operator std::string= (const foo &); // conversion to string operator<= span style=3D"color: #000;" class=3D"styled-by-prettify">
  &= nbsp;  operator foo(const std::string = &); // conversion from string op= erator
};
=


Something else I would really love to see though is using an enum= eration=20
as an underlying ("base") type of an enumeration, e.g.:

   enum class A { a1, a2, ... };
   enum class B : A { b1, b2, ... };

   B bb =3D B::a1; // legal; a1, etc. are in scope of B, inhe= rited from A


But would then be implicit conversions from A all= owed?
B b= b =3D A::a1;
I would suggest not, because this behavior woul= d need to be a special case.

Also, what would be the underlying_type= _t of B? Would it be A or int?

If it could be A, that could be surpr= ising for a lot of code. It would also not play well with Thiago Macieira's= idea of multiple inheritance.

At the same type, it would be interes= ting to have type_traits to query the hierarchy of such enums.

How t= o implement that then? Specialize std::is_base_of?

--

---
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_62_5262444.1395267240238-- .