220 30550 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: Fri, 13 Jan 2017 07:07:06 -0800 (PST) Lines: 330 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_580_700892298.1484320026786" X-Trace: blaine.gmane.org 1484320052 32591 195.159.176.226 (13 Jan 2017 15:07:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jan 2017 15:07:32 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBG624PBQKGQEBITOY4Y@isocpp.org Fri Jan 13 16:07:26 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cS3RX-0006QW-II for gclcip-std-proposals@m.gmane.org; Fri, 13 Jan 2017 16:07:03 +0100 Original-Received: by mail-oi0-f70.google.com with SMTP id v85sf93742544oia.4 for ; Fri, 13 Jan 2017 07:07:08 -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=KOSuNZPaYg9MTUbAHZHNo5SQ5mchGjbZekkx9PGXk78=; b=bkQN4zv6KLtNgU4kWe5KTcXqZSGLomRiMqbe5ViCrrNB3jxnzwwN2/Vl9FdiUwHHki gkO+3SFXSolHMR8ZIJdRklDMufhmgtvtibmzpJ5blmwZ8xVZ1bNloMTSdhppye4BF1GB kXbEMbIUAvfZzWaOXqF6f0T5ZBFK79gFZqUcckDpXkKLXmCn1qs1pI3hJD/fe4dcXyAV JbzTHHvuiN5JTVOz/9aO5MCVJchLZFC8SrmzWMJKLopc9jHVxyZGpIBLd6jCm15rSRNB GXbHLDszXH9VfTKB6LcNMOvbPvajiiulKz5toqJgzlrP/laSsShLVdEQQQ4CLrl9DdeV 3E7w== 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=KOSuNZPaYg9MTUbAHZHNo5SQ5mchGjbZekkx9PGXk78=; b=RxrV1BK2UWyEu+mgMgJd0jnfqN6EFCD5agzEIH862DDPV/ly1x0Q2dny53BxcsYbcl VVOUZ1W+7hPTW8Z/kvSEY2HMxCoIEpJpo2VsWaX8XTHLgn06BHKPkoMa3B+y0KTcO9wp 5/KAQXH1E3YmONhIophh+kKNXhQ8Hj0T+8nzQp/oT0hoFAchvkVr3f1yZ/U7tvJm1up3 UPXbiG7iAFSGJa+CBB6CNr+XhXWLjw2c0LXi3skffau7DWnTPa2BesShqLphXTF4tcXl TlDPV6nUAhWyc0kXrA7CS0+fWkPFg9+L4nvgNzCs3dit2nPcT2mx5XZpTqnQj3kLpu9e DHKg== 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=KOSuNZPaYg9MTUbAHZHNo5SQ5mchGjbZekkx9PGXk78=; b=B00ueLnuGNiadOerqQ+cck6Og+VSEZ+AwZtn9DGxW2lMaJonDZZ+Iu/moq6ZctBsWN yYSsX0U/+S3vPmivA/oqADfHt4gjMgyMJfM36R02yoWuOKU+uUOpH9AuX1V2QePqynj4 8vFOtMZDuE5n0AvShLX1QW/YVsIsP5HX/xAUnaHcS22/IMAaQGBfsO6inYf4jxbPEFXM AlLmHtM+vJDo5lcqnzHee8bgbhmfemR4W5HW0zBcfpoBQ/nxAm+mC9C0bb6jBdpCVRDA oQq/l+Su5dybQGkDDZvb06pAh99gIGUa8nPxXOfITQiMWa1nTbEuLMqd/WXYm1kOzrHb DHDw== X-Gm-Message-State: AIkVDXKAZ8aK4M3seX5X6hHytdagGMwqcgdlYMQc/WFOQP5GmPp4bKM7RIt36cAyvSbOOg== X-Received: by 10.157.47.225 with SMTP id b30mr6277068otd.117.1484320028059; Fri, 13 Jan 2017 07:07:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.45.170 with SMTP id g39ls8949104otb.1.gmail; Fri, 13 Jan 2017 07:07:07 -0800 (PST) X-Received: by 10.157.8.10 with SMTP id 10mr1811821oty.19.1484320027354; Fri, 13 Jan 2017 07:07:07 -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:30550 Archived-At: ------=_Part_580_700892298.1484320026786 Content-Type: multipart/alternative; boundary="----=_Part_581_1904316676.1484320026787" ------=_Part_581_1904316676.1484320026787 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, January 13, 2017 at 2:54:18 AM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > Le 13/01/2017 =C3=A0 01:09, Vicente J. Botet Escriba a =C3=A9crit : > > Le 12/01/2017 =C3=A0 17:07, Nicol Bolas a =C3=A9crit : > > > > On Thursday, January 12, 2017 at 2:28:00 AM UTC-5, Vicente J. Botet=20 > Escriba wrote:=20 >> >> 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 t= hus=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 thi= s=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= =20 >> of 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 co= me=20 > about by using non-scoped, non-fixed enums. > > Thanks this references clarifies the range of valid values. SO the=20 > difference isn't between explicit or not , but between enum and scoped en= um. > > I was wondering if the rationale for the different behavior has something= =20 > to be with the fact that scoped enums can be forward declared. > Any enum with a fixed underlying type can be forward declared. As such, I= =20 imagine that the range rules are not unrelated to that. --=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/a2a01296-f81c-48cf-98f1-52b3af872cef%40isocpp.or= g. ------=_Part_581_1904316676.1484320026787 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Friday, January 13, 2017 at 2:54:18 AM UTC-5, V= icente J. Botet Escriba wrote:
=20 =20 =20
Le 13/01/2017 =C3=A0 01:09, Vicente J. Botet Escriba a =C3=A9crit=C2=A0:
=20
Le 12/01/2017 =C3=A0 17:07, Nicol Bolas a =C3=A9crit=C2=A0:


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=A9= crit=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 (one way or another). And the enum is not being used as a true enumeration, but as a general value that may or may not resolve to one of the enumerators. And you're converting an arbitrary integer int= o that enumeration.

Ultimately, I'm not sure that this confluence of issues comes up often 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 t= he valid range, 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 enumeration type, the underlying type i= s int if it is not explicitly specified. In both of these cases, the underlying type is said to be fixed.

[dcl.enum]/8:

> For an enumeration whose underlying type is fixed, 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'r= e talking about can only come about by using non-scoped, non-fixed enums.
Thanks this references clarifies the range of valid values. SO the difference isn't between explicit or not , but between enum and scoped enum.

I was wondering if the rationale for the different behavior has something to be with the fact that scoped enums can be forward declared.

Any enum with a fixed underlyi= ng type can be forward declared. As such, I imagine that the range rules ar= e not unrelated to that.

--
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/a2a01296-f81c-48cf-98f1-52b3af872cef= %40isocpp.org.
------=_Part_581_1904316676.1484320026787-- ------=_Part_580_700892298.1484320026786-- .