220 30510 <2884ad60-bfb5-5275-bfd1-e741b22b962f@wanadoo.fr> 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: Thu, 12 Jan 2017 08:45:05 +0100 Lines: 434 Approved: news@gmane.org Message-ID: <2884ad60-bfb5-5275-bfd1-e741b22b962f@wanadoo.fr> 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/alternative; boundary="------------3E1E3455E67E5E81844D9169" X-Trace: blaine.gmane.org 1484207129 14606 195.159.176.226 (12 Jan 2017 07:45:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2017 07:45:29 +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+bncBDH67CONY4PBBA7I3TBQKGQE63SHEAY@isocpp.org Thu Jan 12 08:45:23 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRa4F-0001jq-MF for gclcip-std-proposals@m.gmane.org; Thu, 12 Jan 2017 08:45:03 +0100 Original-Received: by mail-wm0-f72.google.com with SMTP id c206sf1793552wme.3 for ; Wed, 11 Jan 2017 23:45:08 -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=jXnNUwqneNeSrtKXcM7IKvzSwFSBfHjdgkcYmRkdszI=; b=p4wiOL4B2dlqGr+YnzmrtWeogzxkjNigvkVkUkOuV0Wd6bWfDcXS51JEGuXHjJsFu+ iw4RsTWiK7NDsxEPSYDr7UQCU4ifrw6Oc60DMHyFGYDZ1gdrKVvL8rM9EVr9ku4l0nZc HbB+S7GzS+JLItmryb6Nou4p7EKp7sgXA4YWI16la9/M3WWHzrcv8/69Ocx4vfTLKiyn /gX/yoWrY8tvsjj27b4d0e7l50xV31jAjwuEVNdie5gaDNofSJudwHcABrLj0N6xLTwc jgbZCQfvSuxsSEUxyRM20fv8oSh86ZKguUBHR72tRNRaS0nkPOM9SXYuHy+DULRSdd+9 Oa3w== 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=jXnNUwqneNeSrtKXcM7IKvzSwFSBfHjdgkcYmRkdszI=; b=lX3vIMkfayGUas/HdC/ybmpbfr/4iKz+I7DJ8Kb+o1ZetXLarpcbTd/ZzPgFbTnTLN bRLXC+TY7DPC+D8l/gBD01DvHXRypvrX+7vQmXzfObbkXlExhW/ObcWxrsQiFJu76Y6/ 8Xrn8/Ki+kf3RWuxR5m93XvTFKOl6GezRz6hkwQ5sFeR6mAhNq8+XF9zX11hpvybdIgN 6xBucQKlVoNVlD7RT/CBm13OMcapwzA22sobJNH6ixX7oP9hQpbmqM6yOWw1RcRO9Zat BmcQt1ic7D0Spm89o3jJEXpE7dDFddpPnpFrEVoqmEvIq1CEYsZORbpxmyWO1YHVou02 9uvg== X-Gm-Message-State: AIkVDXIHf4UDHS0BLFS0DYUNfxp7iRLH1HZkz0wlsHcVoAz9cf/OA6yAhBQOsMoy7S4dNw== X-Received: by 10.194.67.231 with SMTP id q7mr651693wjt.4.1484207108427; Wed, 11 Jan 2017 23:45:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.34.2 with SMTP id i2ls130307wmi.4.canary-gmail; Wed, 11 Jan 2017 23:45:07 -0800 (PST) X-Received: by 10.28.54.226 with SMTP id y95mr7113036wmh.105.1484207107524; Wed, 11 Jan 2017 23:45:07 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr. [80.12.242.135]) by mx.google.com with ESMTPS id lh9si6732764wjc.83.2017.01.11.23.45.07 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 11 Jan 2017 23:45:07 -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 mwinf5d74 with ME id XKl61u00F1UUyQN03Kl6Gx; Thu, 12 Jan 2017 08:45:07 +0100 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 12 Jan 2017 08:45:07 +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:30510 Archived-At: This is a multi-part message in MIME format. --------------3E1E3455E67E5E81844D9169 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 11/01/2017 =C3=A0 21:49, gmisocpp@gmail.com a =C3=A9crit : > >> > 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=20 > 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=20 > not seeing where this happens. The interface you have proposed doesn't introduce any UB, it avoid it,=20 because the test is over a subset of the valid values for an=20 enumeration. The UB is defined in standard. See the paragraph I=20 mentioned. What I'm saying is that we need a function that checks also=20 exactly for the valid values. Is that so complex to understand. >> 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? We are talking here of is_in _enum_rang (or is_valid_enum) by opposition=20 to is_enumerator (your is_enum). is_valid_enum can be implemented easily with the current=20 meta-programming when the underlying type is explict. > I assumed modifying the compiler was a requirement to implement is_enum? I would say that it is easier to maintain if the compiler generates the=20 function. Anyone can define such a function for each enum. > Or maybe you know is_enum can already be implemented through meta=20 > programming without a compiler change? It can with enough meta-programming information, as the one the=20 reflection proposal has, yes. > Or maybe you are talking about modifying the language (so still a=20 > compiler change) but so is_enum can implement this feature? Are you talking of static reflection here? > >> >> 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? The words generic way were in opposition to each particular case. > >> 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 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=3D0, A=3D0x01, B=3D0x02, C=3D0x04, ALL 0x08}; > > and > > enum class Y : unsigned char { NONE=3D0, A=3D0x01, B=3D0x02, C=3D= 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=20 > the type of the enum. > The idea was that those two pieces of information allowed a value to=20 > be constructed that could express any enum as intended. > I'm raising that in case it's helpful to this conversation here but it=20 > might not be because I can't quite follow what problem is being solved=20 > here? It seems that I should not explain myself correctly as people is not=20 understanding the complementary problem I'm raising. The question is : Does your any_enum_value check for the enumerators=20 values or the valid range of the enumeration? 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/2884ad60-bfb5-5275-bfd1-e741b22b962f%40wanadoo.f= r. --------------3E1E3455E67E5E81844D9169 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 11/01/2017 =C3=A0 21:49, gmisocpp@gmail.com a =C3=A9crit=C2=A0:

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.
The interface you have proposed doesn't introduce any UB, it avoid it, because the test is over a subset of the valid values for an enumeration. The UB is defined in standard. See the paragraph I mentioned. What I'm saying is that we need a function that checks also exactly for the valid values. Is that so complex to understand.
=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 sol= ve this as well.

What=C2=A0are you both=C2=A0referring to here?
We are talking here of is_in _enum_rang (or is_valid_enum) by opposition to is_enumerator (your is_enum).
is_valid_enum can be implemented easily with the current meta-programming when the underlying type is explict.
I assumed=C2=A0modifying the compiler was a requirement to implement is_enum?
I would say that it is easier to maintain if the compiler generates the function. Anyone can define such a function for each enum.
Or maybe you know is_enum can=C2=A0already be implemented through meta programming without a compiler change?
It can with enough meta-programming information, as the one the reflection proposal has, yes.
Or maybe you are talking about modifying the language (so still=C2=A0a compiler change) but so is_enum can implement this feature?
Are you talking of static reflection here?


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 generic come into this?
The words generic way were in opposition to each particular case.

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= , 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

=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?

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=C2= =A0a value to be=C2=A0constructed that could express any enum as intended.
I'm=C2=A0raising that in case it's=C2=A0helpful to this conver= sation here but it might not be because I can't quite follow what problem is being solved here?
It seems that I should not explain myself correctly as people is not understanding the complementary problem I'm raising.

The question is : Does your any_enum_value check for the enumerators values or the valid range of the enumeration?

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/2884ad60-bfb5-5275-bfd1-e741b22b962f= %40wanadoo.fr.
--------------3E1E3455E67E5E81844D9169-- .