220 30544 article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: enum_cast proposal Date: Fri, 13 Jan 2017 01:09:26 +0100 Lines: 387 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/alternative; boundary="------------0574014F174652A2B8233757" X-Trace: blaine.gmane.org 1484266175 14905 195.159.176.226 (13 Jan 2017 00:09:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 13 Jan 2017 00:09:35 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBONV4DBQKGQERUUNXOI@isocpp.org Fri Jan 13 01:09:30 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRpQr-00034z-T1 for gclcip-std-proposals@m.gmane.org; Fri, 13 Jan 2017 01:09:26 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id o12sf13889029lfg.7 for ; Thu, 12 Jan 2017 16:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=IL8wluHKHZKHWMeXXLGzPWrfaJsEUutBQLcBtX7jtH4=; b=h46WnScDq5VEPEcvevENjzOBKvnhi0iP6H//PUtm11CB+ZYmw384rbNfmnxWaE1zHF VLcSY1DzGwrKQeJcdipFf3uwQX+QNc7lwAfvVw4cJknh7Rf2qDXvlcDn/KDr08K3NoKR a98rGONlg3MBUZYFKB7sa+8witDbdZc0y9HQCEMTzLI/Qnfy3QHf8y0gRKWAsiiZAFBA NclnGTnWNVVj/sosUwBiRjN/NSCQO6UJMlVgwuVqu11qj71VevjzCh0Tb9D/w96qHBRk yzelXBbAs1mhuTKF7+gFFBmpQm3HA7ETXfEUiDtx1PwLR/5QnYz4yoF7V8TiDWdrvvt5 uP2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=IL8wluHKHZKHWMeXXLGzPWrfaJsEUutBQLcBtX7jtH4=; b=IQ2Kfl5yYyBuUvw9IW90MJ9+dX7myXt5D2mfrCvZ4ILz8REnAHKvTddBMtyi2YnmxL U/hoO70L6dBJRi3rJGK+nx9OS+eeuAPYNi5tG6NC2eFNDGX6RBGS55rZUJQ68xoqYWQn 4fnJ4QenXWiAp6fc9OGMQklZXmyJwVzETS6R9srojE6N/AM8Xj70Z8NWDqtl+FU24dqR IC8Kzt5GGH+ID1jBNRWKvYUJxKpJm7bh+FfBWlMs9ZyQLnU4N3BvGElySTo0Fx2F6qmU 9gPD59TDcP7P8ZttFVW0FzBar8V8FOSPi46SELdCKtKrsXxiil8JhmN52psfjGGVzTxK C/CA== X-Gm-Message-State: AIkVDXI5koAqjkUYGiITNWxFwkYnqE3qWauRCyiEdeo4YTpBIxAt8QW/G/idezydZ6s5lg== X-Received: by 10.25.80.83 with SMTP id z19mr429358lfj.8.1484266170546; Thu, 12 Jan 2017 16:09:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.154.138 with SMTP id c132ls471186wme.6.gmail; Thu, 12 Jan 2017 16:09:29 -0800 (PST) X-Received: by 10.223.128.77 with SMTP id 71mr9306931wrk.48.1484266169310; Thu, 12 Jan 2017 16:09:29 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr. [80.12.242.135]) by mx.google.com with ESMTPS id x200si3599821wme.45.2017.01.12.16.09.29 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 12 Jan 2017 16:09:29 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.135 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.135; Original-Received: from imac-de-vicente-botet-escriba.home ([86.214.89.68]) by mwinf5d70 with ME id Xc9T1u0021UUyQN03c9Ttw; Fri, 13 Jan 2017 01:09:29 +0100 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 13 Jan 2017 01:09:29 +0100 X-ME-IP: 86.214.89.68 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.135 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:30544 Archived-At: This is a multi-part message in MIME format. --------------0574014F174652A2B8233757 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: > > 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 Escriba wrote: >> >> 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 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=20 > not being used as a true enumeration, but as a general value that may=20 > or may not resolve to one of the enumerators. And you're converting an=20 > arbitrary 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 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 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: > > > For a scoped enumeration type, the underlying type is int if it is=20 > not explicitly specified. In both of these cases, the underlying type=20 > is said 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=20 > come 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 enum= .. > >> I believe that you didn't understood my question. Let me see >> with an example. >> What is the difference between >> >> enum class X { NONE=3D0, A=3D0x01, B=3D0x02, C=3D0x04, ALL 0= x08}; >> >> and >> >> 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) > > > 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=20 > not change the rules for the enum range of an enum without a fixed=20 > underlying type. The C++11 behavior contains the C++98 behavior, so it can not be simpler=20 and in my opinion is weird to have a different behavior :) Thanks anyway for the clarifications. Vicente --=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/b2c10414-ec5d-9bc3-dd7e-48bff6f1fa5e%40wanadoo.f= r. --------------0574014F174652A2B8233757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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=A9cr= it=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 into 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 the val= id 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 is 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're 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 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)

The C++11 behavior is much simpler: the range of an enum with a fixed underlying 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.
The C++11 behavior contains the C++98 behavior, so it can not be simpler and in my opinion is weird to have a different behavior :)

Thanks anyway for the clarifications.
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/b2c10414-ec5d-9bc3-dd7e-48bff6f1fa5e= %40wanadoo.fr.
--------------0574014F174652A2B8233757-- .