220 30490 article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: enum_cast proposal Date: Wed, 11 Jan 2017 12:49:57 -0800 (PST) Lines: 306 Approved: news@gmane.org Message-ID: 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_487_1583502401.1484167797668" X-Trace: blaine.gmane.org 1484167801 20333 195.159.176.226 (11 Jan 2017 20:50:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jan 2017 20:50:01 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBB5VU3LBQKGQECUIE4KI@isocpp.org Wed Jan 11 21:49:56 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRPqF-0004d2-1Z for gclcip-std-proposals@m.gmane.org; Wed, 11 Jan 2017 21:49:55 +0100 Original-Received: by mail-pf0-f200.google.com with SMTP id 204sf258956416pfx.1 for ; Wed, 11 Jan 2017 12:49:59 -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=c6PKKc+WqsiFLPhHr1omEgRm0ipOZPPUIEliGxtkhkk=; b=UMjNxPukqGqr5gce7DorYlhTkwLbE+CEasWCwHo7aoVRgz8IRaw3fL+3POLOpsl019 b7Jta70+iUkY5IOfax2oCPGCD9lPrQZjYAhCIbKE0ODRuqb1OU1Zo3elZCRjIWy6plIk sCB8+v2A3IP0hJTmWOqaGiqFn1NjlVfSERbKsJVCF2112IW1F+Pk2cN8AxrsEsU/ejyS LAbdW/IpIb8bM/uZuKAq6S5DoIKBOdld6LJdmsqrl7MswktktunuOvLa2pbZ6MxZxTXx D2MWQB+MLQU7BzkGAEOiTFl2tIIYUiUqc6OT6KCMlH5C2rz7Y94Px9EGfu7BzMjYqs6Y beyA== 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=c6PKKc+WqsiFLPhHr1omEgRm0ipOZPPUIEliGxtkhkk=; b=QYLL+/+xoA2eQt2NxeShMdx1Z/iF0VWp+f8FHRBxDW6NfiP7z/FH4Auz07Oaust0hw McL5/v9/+n82MjUwx23wFniiSzNgyy0+NvJjBqlCdGJ4Gp7pmgNC0lktjJOZmVbK3Ya+ MNEYCYUxCScQdJw4upEi5xCX1R37kaITAx0Zp+P8LC/sIN93/jKu0/qSmZfjbsLgmd0H imMIlkxHEIYqkAqJePIlNdwBqf36Y8Co4ni7nqjVXKxtHKQcdoLKVMUlNZ7DftXSoUkK 2zIcVK+exHr+IxJeKW5R4kCsScqcopc6EjA6UjmnwacZ0wrkprO3rcPHmeUoh8RsBcTg Q90A== 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=c6PKKc+WqsiFLPhHr1omEgRm0ipOZPPUIEliGxtkhkk=; b=PvztbM0lj5Fg0uofOAiuwZ0pe3TrL54925N3lhfzfuhAQNA+IuWbZ4O7jUY2dxlW19 F5LgbESyaLvzp3SeN8mjVMOs/yng/tSZczPFSZaAtdoxFPidIlYrlVDB/SETHdO2DEU9 WAlCCkMMRStdBuRCKEfAvD1kMF1E8KVN9llrK/HxMw2guTMZn8sQ+mPWNrD6qrCfEX6E 4i3FWfefYUKFUPrgxMQM3TTO08MNL/zrrHob6OGK94+P7M6Ur0wpH3tQoVLbXWjtLPr+ ZHiVLH7eCfS0BKOeeLhGOHONtOs2/lfWNsYz9eVUl42fwDSHwtEPPqkgTmmdrw6V6V7F 8mZQ== X-Gm-Message-State: AIkVDXL+NQ43SP3fndog6JFSb9pDUDl08lJBLNVG/DQ0Kz3yfJglNdmn3JvAC/+wDbyPFw== X-Received: by 10.99.140.5 with SMTP id m5mr3544793pgd.95.1484167799145; Wed, 11 Jan 2017 12:49:59 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.137 with SMTP id z9ls5281526otd.28.gmail; Wed, 11 Jan 2017 12:49:58 -0800 (PST) X-Received: by 10.157.14.183 with SMTP id 52mr1117514otj.20.1484167798414; Wed, 11 Jan 2017 12:49:58 -0800 (PST) In-Reply-To: <214358e3-699e-f804-4289-14472559a51a@wanadoo.fr> X-Original-Sender: gmisocpp@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:30490 Archived-At: ------=_Part_487_1583502401.1484167797668 Content-Type: multipart/alternative; boundary="----=_Part_488_455677855.1484167797668" ------=_Part_488_455677855.1484167797668 Content-Type: text/plain; charset=UTF-8 > > > What is important is the range of values. > > > The question I have to ask is this: if you have an integer, why do you > need to know if it will fit within the range of an enum with an implied > underlying type? > > Because initializing the enum with an integer out of range is UB. > In my earlier post where I described at length how I thought the API should be, was there UB in that and if so where? I'm trying to understand where your UB comments are directed as I'm not seeing where this happens. > What problem are you trying to solve? What code are you trying to write? > > If the enum has a fixed underlying type, then you might need to know the > range because you're using the enum as an ad-hoc strongly typed integer. > > Right. > > 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? > But if the enum has an implied underlying type, then why would you need to > know if a particular integer (which does not match any enumerator) is > within the valid range for that enum? > > Because this is legal. I can assign it a value on the specified range. > That's all. If I want my code to be outside the UB world I should be able > to check on the conditions. I can of course do it for each particular case, > but what we are talking of here is about what the compiler could do for us > in a generic way. > The compiler is generating the code so where does generic come into this? What are you trying to do that you need to do this? > > This is not a use case I would write myself, but I've see it a lot of > times. When you use enums as flags of an bitset > enum class X { NONE=0, A=0x01, B=0x02, C=0x04, ALL 0x08}; > > The valid enumerators don't correspond to the valid range, that in this > case is any value between 0 and 8. > > > If you don't have a problem to be solved with such a function, then > there's really no point in adding one. > > I was sure you will ask and say this ;-) > > > I don't know why the new C++11 enum with an explicit underlying type have >> a different range of valid values. >> I'll be interested in knowing the rationale. >> > > Because enums are integers. That's the rationale. > > I believe that you didn't understood my question. Let me see with an > example. > What is the difference between > > enum class X { NONE=0, A=0x01, B=0x02, C=0x04, ALL 0x08}; > > and > > enum class Y : unsigned char { NONE=0, A=0x01, B=0x02, C=0x04, ALL > 0x08}; > ? > > X has a valid range 0..N, while Y has a valid range 0..255. > > Why do we need this difference? Why forcing the underlying type changes > the range of valid values? > I had std::any_enum_value in my earlier post and make_bad_enum knew the type of the enum. The idea was that those two pieces of information allowed a value to be constructed that could express any enum as intended. I'm raising that in case it's helpful to this conversation here but it might not be because I can't quite follow what problem is being solved here? > > Vicente > -- 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/be99b871-2e8f-4c9b-b9f3-dff8543bc38a%40isocpp.org. ------=_Part_488_455677855.1484167797668 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=20
What is important is the range of values.

The question I have to ask is this: if you have an integer, why do you need to know if it will fit within the range of an enum with an implied underlying type?
Because initializing the enum with an integer out of range is UB.

In my earlier post where I described a= t length how I thought the API should be, was there UB in that and if so wh= ere?
I'm trying to understand where your UB comments are dire= cted as I'm not seeing where this happens.
=C2=A0
What problem are you trying to solve? What code are you trying to write?

If the enum has a fixed underlying type, then you might need to know the range because you're using the enum as an ad-hoc strongly typed integer.
Right.
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?


But if the enum has an implied underlying type, then why would you need to know if a particular integer (which does not match any enumerator) is within the valid range for that enum?
Because this is legal. I can assign it a value on the specified range. That's all. If I want my code to be outside the UB world I should be able to check on the conditions. I can of course do it for each particular case, but what we are talking of here is about what the compiler could do for us in a generic way.

The compiler is generating the code so=C2=A0where does ge= neric come into this?

What are you trying to do that you need to do this?
This is not a use case I would write myself, but I've see it a lot of times. When you use enums as flags of an bitset
enum class X { NONE=3D0, A=3D0x01, B=3D0x02, C=3D0x04, ALL 0x08};

The valid enumerators=C2=A0 don't correspond to the valid range, th= at in this case is any value between 0 and 8.

If you don't have a problem to be solved with such a function= , then there's really no point in adding one.
I was sure you will ask and say this ;-)

I don't know why t= he new C++11 enum with an explicit underlying type have a different range of valid values.
I'll be interested in knowing the rationale.

Because enums are integers. That's the rationale.
I believe that you didn't understood my question. Let me see with a= n example.
What is the difference between

=C2=A0=C2=A0=C2=A0 enum class X { NONE=3D0, A=3D0x01, B=3D0x02, C=3D0x0= 4, ALL 0x08};

and

=C2=A0=C2=A0=C2=A0 enum class Y : unsigned char { NONE=3D0, A=3D0x01, B= =3D0x02, C=3D0x04, ALL 0x08};
?

X has a valid range 0..N, while Y has a valid range 0..255.

Why do we need this difference? Why forcing the underlying type changes the range of valid values?

I had std::any_enum_value in my earlier post and make_bad_enum knew t= he type of the enum.
The idea was that those two pieces of inform= ation allowed=C2=A0a value to be=C2=A0constructed that could express any en= um as intended.
I'm=C2=A0raising that in case it's=C2=A0h= elpful to this conversation here but it might not be because I can't qu= ite follow what problem is being solved here?
=C2=A0

Vicente

--
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/be99b871-2e8f-4c9b-b9f3-dff8543bc38a= %40isocpp.org.
------=_Part_488_455677855.1484167797668-- ------=_Part_487_1583502401.1484167797668-- .