220 9952 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: Thu, 20 Mar 2014 12:12:02 -0400 Lines: 65 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> <532A2217.10905@users.sourceforge.net> 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 1395331935 11612 80.91.229.3 (20 Mar 2014 16:12:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 16:12:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCO5FYHBU4ERBYVGVSMQKGQEEQ7WBOI@isocpp.org Thu Mar 20 17:12:23 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f198.google.com ([74.125.82.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQfZr-0007vw-8t for gclcip-std-proposals@m.gmane.org; Thu, 20 Mar 2014 17:12:19 +0100 Original-Received: by mail-we0-f198.google.com with SMTP id u57sf1559569wes.1 for ; Thu, 20 Mar 2014 09:12: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:to:from:subject:date:lines:message-id:references :mime-version:user-agent: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=3KeJiHxVelnZ5ASopyvyPUykZOaDvZIIGUhEhRNLZ9I=; b=S1sOGpn+Sw7Y30PShw52hqDtmuXnBxd9pWEJbSG565aZI6JUYMctV+80sjT+3CkLRW RF2Rn26EEIxRwcCfTrkdAIbu0Tx5lkDdQ6cg9QjD1obbodxbXjo+MTq7mKnf2dbDn/7R zx67VsOV8u0+7kMRFSxea/vHJuIwi/L25GmHvhjANkrElkS/8LWJBQKnTTWqf7ZdJihi Wfa6wpGl7oi+e2LUiwULUBVwfgZgaruzSuwOOXoBpRHZaIt8y+6ofZUpU2+AnuyyrAYa HEPVHy2LZ5RiPHE1ggb/jOmTNlwK4RzNFH21w1gYyUOV7ThocomH/pnA6Si4JE8gDHXe MwHA== X-Gm-Message-State: ALoCoQlBzRly++bh9okAjnRrvD8r9NuSptku0mpRWSUM3eDElZ9F9YWjF94OmxsvNp0aylu65fwd X-Received: by 10.112.20.194 with SMTP id p2mr1535112lbe.21.1395331938962; Thu, 20 Mar 2014 09:12:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.37.163 with SMTP id z3ls46143laj.66.gmail; Thu, 20 Mar 2014 09:12:17 -0700 (PDT) X-Received: by 10.112.89.234 with SMTP id br10mr1066999lbb.60.1395331937709; Thu, 20 Mar 2014 09:12:17 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id e6si1894261lah.16.2014.03.20.09.12.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 20 Mar 2014 09:12:17 -0700 (PDT) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WQfZo-0007rz-0m for std-proposals@isocpp.org; Thu, 20 Mar 2014 17:12:16 +0100 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Mar 2014 17:12:16 +0100 Original-Received: from mw_triad by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Mar 2014 17:12:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 56 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: X-Original-Sender: mw_triad@users.sourceforge.net X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mail=gclcip-std-proposals@m.gmane.org 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:9952 Archived-At: On 2014-03-19 19:33, Matheus Izvekov wrote: > On Wednesday, March 19, 2014 8:02:47 PM UTC-3, Matthew Woehlke wrote: >> 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. > > It's also kind of the opposite behavior of an enum class deriving from int > though, where implicit conversions both ways are disallowed. True, but an enum is a *restricted* subclass of e.g. int. Given the previous example: enum class A : int { ... }; enum class B : A { ... }; ....the idea is that all possible values of A are possible values of B. But clearly not all possible values of int are possible values of A. So obviously promotion from int to A does not make sense, but promotion from A to B could make sense. (Similarly, *de*motion for B to A probably does not make sense and would be disallowed.) I think the question is, do we write the rules to make the most sense when considered in isolation, or when considered against "similar" implicit conversion rules for other types? Or do we take the cop-out and just disallow all implicit conversions? My own inclination is to the first, but it's not a strong inclination. > On the other hand, IMHO making enum classes have similar semantics to > opaque typedefs seems a lot simpler > and fits better, because as they stand right now, they are a lot like an > opaque typedef, but unfortunately support just fundamental integers. Here maybe is a way to look at it... an enum class is an opaque typedef with an underlying integer type (say, will std::underlying_type work on an opaque typedef?), which: - Has a convenient syntax for providing a list of static members which are constexpr values of the type initialized from a value of the base type. - May inherit from one or more enumerations, such that the values of the base enumerations are accessible as values of the derived enumeration, having the derived type when references via the same. (Except when deriving 'private'; see next point.) - Has reversed order of permissible implicit conversion (i.e. a Base may convert to a Derived, but not vice versa) versus an "ordinary" opaque typedef. Probably given similar rules, e.g. 'protected' prevents implicit conversion, 'private' also hides values of base enum. ....and ideally allow 'member functions' (including constructors and conversion operators) for opaque typedefs (not just enum class's) as well. -- 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/. .