220 30526 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: Thu, 12 Jan 2017 08:07:21 -0800 (PST) Lines: 338 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> <0a4162ad-62ed-1c26-e210-81000402b193@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_732_2122343943.1484237241971" X-Trace: blaine.gmane.org 1484237262 6826 195.159.176.226 (12 Jan 2017 16:07:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2017 16:07:42 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBO6T33BQKGQE3IISLAI@isocpp.org Thu Jan 12 17:07:37 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRhuJ-0008G1-HT for gclcip-std-proposals@m.gmane.org; Thu, 12 Jan 2017 17:07:19 +0100 Original-Received: by mail-pf0-f199.google.com with SMTP id 127sf56446910pfg.5 for ; Thu, 12 Jan 2017 08:07:24 -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=wvtk65h6FFS1I6Kl33w065bgihhcjdSkaL4IGtimowE=; b=KEjWrxogNCMmHux15VpLYPOgthCveSSlT0bcWOfstfm6FuJEUhUk/D0Db3Y/ppS+c9 JlJWr12wPqywRPrSV83+nMpFM10Bvus3zjZqBPZKx8f9bhbmgRrpSr/kF0Wd1heU//cD qx0ehP6Lf5IkSHBU8W4s3ZQsD1ofo+GpiIuK1wI6Tfu4CfW8ePkCFK8uYDtzAkKAqhAE S0h0VIsSWjmJ2dSptm7ptrpWImX4jnM5cAbkSvPxmk8byWfMlSFkkafThfqT0YzOLEz5 MbYOhbk0107r65fpGg3w/x9uaBS2JSkc/3eQZ8AOBYVbt3gaie2hroQdfkvd8nQwdJjj 96GA== 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=wvtk65h6FFS1I6Kl33w065bgihhcjdSkaL4IGtimowE=; b=UjeOOQezeA/AXw2iLSRGDhw6iSHiAshnfWPg6q4IL6hmZ1JdTQO9UmCrHRnLbjvnJm 7bhBUKZTWy6PuviGPXcPjLI3n5tu9sG+QSZX1HhwqhpLIDNhf6KtaqPczSw6NbjHzCY0 emGAD7+4LL/eqlfZ2FJZawUYuYDd4hkIKshk1876JngkKZbSr6YzgyVXwt+i2ueM4RSc /6W9Ol8XRwx93l2lY0Uk4nfdTvhnyhQajbGZQGQvtRAvdy1kKVkc5FdJu0r6y2o3AU4J 5YM4etEpNEGs8uhN9P+Erp0Zo5OuDr3XJ6f+c6SzJUw9/rsLaaI4S9i9jFkQN4zFb4k5 sw4Q== 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=wvtk65h6FFS1I6Kl33w065bgihhcjdSkaL4IGtimowE=; b=kx47+lokESmulV+OLLESN/KOWB0LPyB/8rgG/jLMhIrxeJ9Wqc/tcGPjchrM56Hvou b15tDe5HT6wLjkjSfRPEl8nktRK4LANp0itFFeYyzmMXIUBLcD1S5VBqPrkSElD1Z6IM JSyGIXg+H2ev8uaAih22+wjV9CITIiX4r89wlkS+rlM5xiSslLcAuxNXCwCgQuwgKJL/ PuuZEN8XTcfju2RArGf3Nq0fSLDiQ7RN2QIpQrlST87ycb7QDT5N2rpQ7rx6SeFuTwfA 2q1WClbwJKnxfM7D2qG3HCkWPTDAwBM3JkqQ1p6635dRoSxj6M0UoridrHlj4ZWhz7fx 8Rwg== X-Gm-Message-State: AIkVDXLcpwqu45NVWMfyc4BHbl5mBmS1kMqOkRme1xOGZlaDdbvFM2hClXOjnHr9vuISTg== X-Received: by 10.99.253.69 with SMTP id m5mr5344271pgj.28.1484237243926; Thu, 12 Jan 2017 08:07:23 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.21.124 with SMTP id z57ls7151459otz.38.gmail; Thu, 12 Jan 2017 08:07:23 -0800 (PST) X-Received: by 10.157.14.183 with SMTP id 52mr1394860otj.20.1484237243237; Thu, 12 Jan 2017 08:07:23 -0800 (PST) In-Reply-To: <0a4162ad-62ed-1c26-e210-81000402b193@wanadoo.fr> 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:30526 Archived-At: ------=_Part_732_2122343943.1484237241971 Content-Type: multipart/alternative; boundary="----=_Part_733_1307729811.1484237241972" ------=_Part_733_1307729811.1484237241972 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, January 12, 2017 at 2:28:00 AM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > Le 11/01/2017 =C3=A0 22:21, Nicol Bolas a =C3=A9crit : > > On Wednesday, January 11, 2017 at 1:52:11 PM UTC-5, Vicente J. Botet=20 > Escriba wrote:=20 >> >> Le 11/01/2017 =C3=A0 00:06, Nicol Bolas a =C3=A9crit : >> >> On Tuesday, January 10, 2017 at 5:26:11 PM UTC-5, Vicente J. Botet=20 >> Escriba wrote:=20 >> >> >> The question I have to ask is this: if you have an integer, why do you= =20 >> need to know if it will fit within the range of an enum with an implied= =20 >> underlying type? >> >> Because initializing the enum with an integer out of range is UB. >> > > You're misunderstanding my question. > > The situation you describe is one where: > > 1. You have an integer of arbitrary origin. > > 2. You want to convert it to an enum type. > > 3. That integer *does not match* one of the enumerators in that type. > > 4. The enum type does not have a fixed underlying type. > > You have described very well the context. > > What goal are you trying to achieve with all this? Or more to the point,= =20 > why are you incapable of simply giving the enum an underlying type and th= us=20 > making the question moot? > > Because the enum is declared in a 3pp library in C++98? or a common part= =20 > that is shared by an application using C++98 and another using C++2x? > So the enum is in legacy code (one way or another). And the enum is not=20 being used as a true enumeration, but as a general value that may or may=20 not resolve to one of the enumerators. And you're converting an arbitrary= =20 integer into that enumeration. Ultimately, I'm not sure that this confluence of issues comes up often=20 enough that we need a mechanism to check for it. > This is not a use case I would write myself, but I've see it a lot of=20 >> 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 don't correspond to the valid range, that in this= =20 >> case is any value between 0 and 8. >> > > But we can already answer that question. `X` is an `enum class`. As such,= =20 > it *always* has a fixed underlying type. If you don't specify one, then= =20 > it shall be `int`, and therefore `X` can legally assume any `int` value. > > From the text of the standard I send before, the range is not the range o= f=20 > int. Could you point me from where are you concluding this? > [dcl.enum]/5: > For a scoped enumeration type, the underlying type is int if it is not= =20 explicitly specified. In both of these cases, the underlying type is said= =20 to be fixed. [dcl.enum]/8: > For an enumeration whose underlying type is fixed, the values of the=20 enumeration are the values of the underlying type. So the range of a scoped enumeration is *always* the range of its=20 underlying type. Therefore the situation you're talking about can only come= =20 about by using non-scoped, non-fixed enums. > I believe that you didn't understood my question. Let me see with an=20 >> example.=20 >> What is the difference between >> >> enum class X { NONE=3D0, A=3D0x01, B=3D0x02, C=3D0x04, ALL 0x08}; >> >> and=20 >> >> enum class Y : unsigned char { NONE=3D0, A=3D0x01, B=3D0x02, C=3D0x0= 4, ALL=20 >> 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= =20 >> the range of valid values? >> > > In that case, both have a forced underlying type, as I pointed out above.= =20 > So the reason for the differing ranges of values is obvious. > > Now, let's assume you have revised your example to not use `enum class`.= =20 > `enum X` does not have a fixed underlying type, so its range is determine= d=20 > by its enumerators. The reason that is different is because that's how it= =20 > always was before, and there's terribly little reason to change it. > > I'm not questioning the old C++98 behavior but the new C++11 behavior (if= =20 > we can say new for C++11) > The C++11 behavior is much simpler: the range of an enum with a fixed=20 underlying type is the range of its fixed underlying type. C++11 did not=20 change the rules for the enum range of an enum without a fixed underlying= =20 type. --=20 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 e= mail 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/d4065d2b-f8b7-4b55-ba43-65895c14e0bb%40isocpp.or= g. ------=_Part_733_1307729811.1484237241972 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thursday, January 12, 2017 at 2:28:00 AM UTC-5,= Vicente J. Botet Escriba wrote:
Le 11/01/2017 =C3=A0 22:21, Nicol Bolas a =C3=A9crit=C2=A0:
On Wednesday, January 11, 2017 at 1:52:11 PM UTC-5, Vicente J. Botet Escriba wrote:
Le 11/01/2017 =C3=A0 00:06, Nicol Bolas a =C3=A9crit=C2=A0= :
On Tuesday, January 10, 2017 at 5:26:11 PM UTC-5, Vicente J. Botet Escriba wrote:

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.

You're misunderstanding my question.

The situation you describe is one where:

1. You have an integer of arbitrary origin.

2. You want to convert it to an enum type.

3. That integer does not match one of the enumerators in that type.

4. The enum type does not have a fixed underlying type.

You have described very well the context.
What goal are you trying to achieve with all this? Or more to the point, why are you incapable of simply giving the enum an underlying type and thus making the question moot?
Because the enum is declared in a 3pp library in C++98? or a common part that is shared by an application using C++98 and another using C++2x?

So the enum is in legacy code (on= e way or another). And the enum is not being used as a true enumeration, bu= t as a general value that may or may not resolve to one of the enumerators.= And you're converting an arbitrary integer into that enumeration.
<= br>Ultimately, I'm not sure that this confluence of issues comes up oft= en enough that we need a mechanism to check for it.
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 r= ange, that in this case is any value between 0 and 8.

But we can already answer that question. `X` is an `enum class`. As such, it always has a fixed underlying type. If you don't specify one, then it shall be `int`, and therefore `X` can legally assume any `int` value.
From the text of the standard I send before, the range is not the range of int. Could you point me from where are you concluding this?

[dcl.enum]/5:

>=C2=A0 For a scoped e= numeration type, the underlying type is int if it is not explicitly specifi= ed. In both of these cases, the underlying type is said to be fixed.
[dcl.enum]/8:

> For an enumeration whose underlying type is fixe= d, the values of the enumeration are the values of the underlying type.
=
So the range of a scoped enumeration is always the range of its = underlying type. Therefore the situation you're talking about can only = come about by using non-scoped, non-fixed enums.
I believe that you didn= 't understood my question. Let me see with an example.
What is the difference between

=C2=A0=C2=A0=C2=A0 enum class X { NONE=3D0, A=3D0x01, B=3D0x02,= C=3D0x04, 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?

In that case, both have a forced underlying type, as I pointed out above. So the reason for the differing ranges of values is obvious.

Now, let's assume you have revised your example to not use `enum class`. `enum X` does not have a fixed underlying type, so its range is determined by its enumerators. The reason that is different is because that's how it always was before, and there's terribly little reason to change it.
I'm not questioning the old C++98 behavior but the new C++11 behavior (if we can say new for C++11)

T= he C++11 behavior is much simpler: the range of an enum with a fixed underl= ying type is the range of its fixed underlying type. C++11 did not change = the rules for the enum range of an enum without a fixed underlying type.

--
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/d4065d2b-f8b7-4b55-ba43-65895c14e0bb= %40isocpp.org.
------=_Part_733_1307729811.1484237241972-- ------=_Part_732_2122343943.1484237241971-- .