220 30493 <876d94f3-acbd-4279-9708-d6edf6f5b311@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: enum_cast proposal Date: Wed, 11 Jan 2017 13:25:48 -0800 (PST) Lines: 122 Approved: news@gmane.org Message-ID: <876d94f3-acbd-4279-9708-d6edf6f5b311@isocpp.org> References: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> <24e58aad-ecbc-4c83-a21b-de56ea4c1db0@isocpp.org> <040e99e3-8f07-409f-3a47-ebdfb2bfb465@wanadoo.fr> <1841091b-9f97-4724-9f95-3193c0fb94fb@isocpp.org> <214358e3-699e-f804-4289-14472559a51a@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1277_154112377.1484169948202" X-Trace: blaine.gmane.org 1484169967 31283 195.159.176.226 (11 Jan 2017 21:26:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jan 2017 21:26:07 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBXOF3LBQKGQEAHVHA6A@isocpp.org Wed Jan 11 22:26:02 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRQOv-0006F2-At for gclcip-std-proposals@m.gmane.org; Wed, 11 Jan 2017 22:25:45 +0100 Original-Received: by mail-yb0-f199.google.com with SMTP id 63sf275407ybr.7 for ; Wed, 11 Jan 2017 13:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=sNNB3RuuB5JWJaVE0UQRJzN5mNqtj7cvcMKLvGc4apQ=; b=H9TO+14aqGxvPJkkjNTrfO7tBfZwq95Ip8hZKe35CJv61DCMlJo3ImdgjIwr7/rKMh 6dxJX9j9bp+GldOunIuKN48mCDEvyAq1q57TzzbXSMYXlYBLJxv+qLSmCS7OkN01UR+M /MgQ8YYWYO1cVAhreFMxzgrulvtXBGbkHTMyOyRCZCTNyM4GGGnuZiwRtOFLPpvH0FYC 6VpvKgMhSkW7+xhdrKxP7V8xKxNLUPQAyh749anR2B5+wqNF8yu3wY3mBU0CIqj7OoL8 Wu1ac6Ki6cJA+4pUWeZvxhXB1F0jWP7HgjqGTFVUWSRcRIq6HP4MvP0e9tlaOW4Z+OVH FDpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=sNNB3RuuB5JWJaVE0UQRJzN5mNqtj7cvcMKLvGc4apQ=; b=GkEHi78Jl8QllxGJkcjVP/e3wQgIG0z7M6bT0XysWY6NXsp+Hq2xthrA2x/2Gu+a5p VfUxDEDUkSifdA4416QtBPh32dAFWV4H0TBXrOYKbJEn9tmTy+QweX766OtGHPWggnqe cxZTAYZgQdZwfWe3whpzuytyexL+0HmMje+m4h4TNbwmiz0EHa8Ix3cEUQATQBFaMyXH a0B0tJq+yh6EXh5YDYs0Who5dVdEEh+7bPMp0dsTeijnwy6tDlMamBPAGf+LMEfzkPs+ XBPtDERR5OLInPUvVDabHdrWryzHRvXBJkXwBYYM589DLZB+nebm5j8y2nXI2NAWO5+s 0tvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=sNNB3RuuB5JWJaVE0UQRJzN5mNqtj7cvcMKLvGc4apQ=; b=jvnkCGcB+a/CwK4uT4PXT3LgBqFhgsEEyWjqJdB1IEfgBQF0cmSMR+IafPG5sE3JwK IwXGSJnA75K22VNslW/QXZX73Vi8zZts1ZIJ1ypYF+ZUSUsGDSTuND4Gr/crUP9vyBlc N44xWkfCdPNnE9JCmoLKFg+67POtUOpJXrsAaTdVGz2ywP1WJXx/JsYyVmzBmwKaFXfc BWPYV6Lx+P4SIwny1iBdV85dp+dXnnQ3lJKt+hBpvyqp+RTX/1tWy4+mgRQTXmSb8VTY yyEt5f65lkMERwHQD8I4Lw3zgKY/KRqAM5U6g6eNRz771NhbCdX/GHChEtxf3eASiKfQ KDOg== X-Gm-Message-State: AIkVDXJ63zg7bJFd3HHMvXsy6bhmu3ND/YNFUgpdq2j/REtI/bMH3ZFuupebMidfE13mnw== X-Received: by 10.129.50.77 with SMTP id y74mr3322210ywy.95.1484169949583; Wed, 11 Jan 2017 13:25:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.39.52 with SMTP id r49ls4767772ota.45.gmail; Wed, 11 Jan 2017 13:25:48 -0800 (PST) X-Received: by 10.157.12.165 with SMTP id b34mr1140321otb.2.1484169948915; Wed, 11 Jan 2017 13:25:48 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:30493 Archived-At: ------=_Part_1277_154112377.1484169948202 Content-Type: multipart/alternative; boundary="----=_Part_1278_2021335993.1484169948202" ------=_Part_1278_2021335993.1484169948202 Content-Type: text/plain; charset=UTF-8 On Wednesday, January 11, 2017 at 3:49:57 PM UTC-5, gmis...@gmail.com wrote: > > I personally despise this obvious abuse of a language feature, but C++17 >> has effectively canonized it, so there it is. Alternatively, you may be >> using that enum as a bitfield. >> >> The thing is, that is a solved problem: get the underlying type with >> `std::underlying_type_t`. That, and its corresponding `numeric_limits` >> will tell you everything you need to know about the range of that >> enumeration. >> >> I don't want to solve problems that are already solved. We don't need any >> modification on the compiler to solve this case, but if it solve the more >> dificult case it could solve this as well. >> > > What are you both referring to here? I assumed modifying the compiler was > a requirement to implement is_enum? > Or maybe you know is_enum can already be implemented through meta > programming without a compiler change? > Or maybe you are talking about modifying the language (so still a compiler > change) but so is_enum can implement this feature? > This conversation is separate from most of the rest of the thread. The standard defines the difference between the range of values that are legal for an enum type and the enumerators for that enum. `is_enum` answers the latter question: is the integer one of the enumerators? What Vicente wants is an answer to the former question: is the integer's value within the range of the enumeration? The reason it's non-trivial to implement yourself is because, for enums with an implied underlying type, the valid range of the enumeration is defined by the values of the enumerators, rather than the compiler-selected underlying type. There's no way to compute that require reflection or compiler gymnastics. My main point of contention for the feature is why someone needs to ask it. I don't feel Vicente has given sufficient justification for it. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/876d94f3-acbd-4279-9708-d6edf6f5b311%40isocpp.org. ------=_Part_1278_2021335993.1484169948202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, January 11, 2017 at 3:49:57 PM UTC-5, gmis..= ..@gmail.com wrote:
I personally despise this obvious abuse of a language feature, but C++17 has effectively canonized it, so there it is. Alternatively, you may be using that enum as a bitfield.

The thing is, that is a solved problem: get the underlying type with `std::underlying_type_t<E>`. That, and its corresponding `numeric_limits` will tell you everything you need to know about the range of that enumeration.
I don't want to solve problems that are already solved. We don'= t need any modification on the compiler to solve this case, but if it solve the more dificult case it could=C2=A0 solve this as well.

What=C2=A0are you both=C2=A0referring to= here? I assumed=C2=A0modifying the compiler was a requirement to implement= is_enum?
Or maybe you know is_enum can=C2=A0already be impl= emented through meta programming without a compiler change?
Or ma= ybe you are talking about modifying the language (so still=C2=A0a compiler = change) but so is_enum can implement this feature?

This conversation is separate from most of the rest of the t= hread.

The standard defines the difference between the range of valu= es that are legal for an enum type and the enumerators for that enum. `is_e= num` answers the latter question: is the integer one of the enumerators? Wh= at Vicente wants is an answer to the former question: is the integer's = value within the range of the enumeration?

The reason it's non-t= rivial to implement yourself is because, for enums with an implied underlyi= ng type, the valid range of the enumeration is defined by the values of the= enumerators, rather than the compiler-selected underlying type. There'= s no way to compute that require reflection or compiler gymnastics.

= My main point of contention for the feature is why someone needs to ask it.= I don't feel Vicente has given sufficient justification for it.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/876d94f3-acbd-4279-9708-d6edf6f5b311= %40isocpp.org.
------=_Part_1278_2021335993.1484169948202-- ------=_Part_1277_154112377.1484169948202-- .