220 9928 <532A2217.10905@users.sourceforge.net> article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Explicitly-defaulted enumeration operators Date: Wed, 19 Mar 2014 19:02:47 -0400 Lines: 85 Approved: news@gmane.org Message-ID: <532A2217.10905@users.sourceforge.net> 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: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1395270166 30796 80.91.229.3 (19 Mar 2014 23:02:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 23:02:46 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDL7XH736INRBG6EVCMQKGQEIWCCZHI@isocpp.org Thu Mar 20 00:02:53 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f200.google.com ([209.85.160.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQPVc-0005ZA-Ti for gclcip-std-proposals@m.gmane.org; Thu, 20 Mar 2014 00:02:53 +0100 Original-Received: by mail-yk0-f200.google.com with SMTP id q9sf189556ykb.3 for ; Wed, 19 Mar 2014 16:02:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state: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=OWMe2G1esKz2lGrcQdIZXRWmMK4/9k4FjsnLm0f6b5o=; b=IJBWrH6SaO9QReKsRDBoGI3rjZ8bzfg1LriYMaHyI9b8mWfhHt0KW+uIgQC1Warnmm cAjGF7TaLta8rQKdIt/JN94Ym1siOfiO6K4/srl7gkaZf9+oY/URzXhTw9d0DsXxI96Z j9rJQpgsKlno60C7zwoJQ6o+nfbgqlxKEeSZkVIsWU5K4cCsa1vIqKBVlclDNIBavNpt CjwQy+ZT60AHpUdE1MBsIKwrdwxtycxYurOQJA0eOhWBd6DEA/M5fWNUrTz85c7QQ0GK fnE7on8AsnYbty1cCAXoMJeBjLAf40PFTiQNcFqA9HlisNB5ySiW5vim5DGlajfB+650 XIzw== X-Gm-Message-State: ALoCoQmV16Pyk2aH3+mDBF4ZMhc8cc8b0GwXM42BG8yitnnYbxHoPxKTcDip7MwyrdjDuEkUfdQa X-Received: by 10.236.98.104 with SMTP id u68mr12859344yhf.1.1395270172125; Wed, 19 Mar 2014 16:02:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.7.106 with SMTP id i10ls4549oba.7.gmail; Wed, 19 Mar 2014 16:02:51 -0700 (PDT) X-Received: by 10.60.73.164 with SMTP id m4mr34855346oev.8.1395270171076; Wed, 19 Mar 2014 16:02:51 -0700 (PDT) Original-Received: from na6sys009bog035.obsmtp.com ([74.125.150.109]) by mx.google.com with SMTP id yv5si56oeb.108.2014.03.19.16.02.50 for ; Wed, 19 Mar 2014 16:02:51 -0700 (PDT) Received-SPF: pass (google.com: domain of matthew.woehlke@kitware.com designates 74.125.150.109 as permitted sender) client-ip=74.125.150.109; Original-Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na6sys009bob035.postini.com ([74.125.148.12]) with SMTP ID DSNKUyoiGsYWDFzLeKli9K7Q3p4OcnOzMZ1E@postini.com; Wed, 19 Mar 2014 16:02:50 PDT Original-Received: by mail-ig0-f177.google.com with SMTP id ur14so378846igb.4 for ; Wed, 19 Mar 2014 16:02:49 -0700 (PDT) X-Received: by 10.43.155.84 with SMTP id lh20mr69769icc.81.1395270169640; Wed, 19 Mar 2014 16:02:49 -0700 (PDT) X-Received: by 10.43.155.84 with SMTP id lh20mr69758icc.81.1395270169477; Wed, 19 Mar 2014 16:02:49 -0700 (PDT) Original-Received: from [192.168.1.181] (tripoint.kitware.com. [66.194.253.20]) by mx.google.com with ESMTPSA id u1sm796322igm.8.2014.03.19.16.02.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 16:02:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: X-Original-Sender: matthew.woehlke@kitware.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of matthew.woehlke@kitware.com designates 74.125.150.109 as permitted sender) smtp.mail=matthew.woehlke@kitware.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:9928 Archived-At: (I'm leaving the entirety of Matheus text as something appears to have eaten that message...) On 2014-03-19 18:14, Matheus Izvekov wrote: > 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. Sure. I'm not inclined to believe they're the same proposal. Just saying, I'd really like the above :-). > 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. Heh. I had one originally, and decided to remove it because I'm not sure of the answer :-). Intuitively I would say "yes", because if all values of A are also values of B, it makes sense to allow promotion from A to B, unless such has been explicitly denied. On the other hand though, it's opposite what implicit type conversions are allowed for class pointers / references. But maybe it would be more like numeric promotions, e.g. A -> B is sort of like char -> int. > 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? Probably 'int', a) for the reasons you give above, and b) because I do think multiple inheritance should be allowed. And I would further agree that obtaining type 'A' from type 'B' should use the same mechanism as for "true" classes (which among other things would imply that is_base_of(A, B) => true). -- Matthew -- --- 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/. .