220 30515 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: Thu, 12 Jan 2017 03:35:30 -0800 (PST) Lines: 544 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> <2884ad60-bfb5-5275-bfd1-e741b22b962f@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_468_2126305148.1484220930768" X-Trace: blaine.gmane.org 1484220949 13944 195.159.176.226 (12 Jan 2017 11:35:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2017 11:35:49 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBA6U3XBQKGQEIKIU6BI@isocpp.org Thu Jan 12 12:35:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRdfD-0001k6-QV for gclcip-std-proposals@m.gmane.org; Thu, 12 Jan 2017 12:35:28 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id x84sf31094642oix.7 for ; Thu, 12 Jan 2017 03:35:32 -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=ZN2u3mK+qHi+SjjidZM1mRFHxNO6iQDa+kIjBfk4alw=; b=rXBK/+p4PnWC/aJmXNnjfA9xOEcvDTlcyCklsOgqGDJG+8gshoLk5RgWDdC9cVmyq7 IY9HBsRxgEw+SNBhyfuRtjgBVvHWlwfHBKz9CUPEn3oGABk7twx/88LZPlUYnYh7Hlx4 9pCpJcqtoyONwjoEf4aWHGbjoAD4HNrLWnkrmTt6j/kTYAiSiUAQwvvF9uDpgCfl+9yV ZtOJw5YQgPCDb2RB5tNidqOu0mD8zP9a/uH92PL/Wac5bXPHajU31a4w5+Wdn6SP8Hrw ere2A8OCkiefmqLevTH3fUlYRxfNHZgF26WQfEOtol6aIX5OL3Er2jou4KhYdYSegWsl u+OQ== 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=ZN2u3mK+qHi+SjjidZM1mRFHxNO6iQDa+kIjBfk4alw=; b=ZZv87zurErMTA6ie4CRDppwFUM04T6jesb9WW2Vy1ejXhX7Mzn+ZP/T33oxzoL8vJp bvik6sRF/dUBE6tLdRSYsLi/9xXD5IZ5RlO0SBz2eHd2Gi/EtichtYOSXhBZggc10/8M w/r00DLgChPirrC6mWLlUpxfuT2ByVNIs0G1uKlY08x4168zQqnKjVlAaPjsplC1BWj+ XFeJbNFMm1uSH4ZkNnsdmYvJAs79mgDyHya29FVlU0lSW0oyfu+x/Is+lnqla71Qcork N4cjQ6Jx6npFXdTGb8GiTBvGB2tv7I7OwOZyYUfVKZnGYCTWZlz9kKZqyWYZZxiutHtm bSRA== 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=ZN2u3mK+qHi+SjjidZM1mRFHxNO6iQDa+kIjBfk4alw=; b=FWdfhIGj6i/pQHl2kylCa+35P+jRO79EVOZORqQbRj7ubaxbjHE9v2BTNcmBv+2wHK Bolm62dpwch8k9dO50eEp47LC664avDyCSqbzlDDkEnucHd5onvYtWUq5pPgOCNoCblF KsgkdhNIGhkphjJ0OGGIV1/sWaEy39Y+kG3SooM1BX810YPeH87dffqIX3FDtLg59itW dE/Kg1GHz4n28Dn+EVe+UedliHMCd6DtAwEmclpd8bi7Ik7Njw1Do8gb6TSUue7iKGai C+gQ+f7v1209ZhTM3eVs9I2iAhS5N+LSjIIwiki8voOHs181/kbxvchQ8/OX+r05XseD o1/Q== X-Gm-Message-State: AIkVDXKf+Gofng1MEkX8fZMvpeiKlyqKJ0cXrUsQjM1RPQfd20JV7OImARR4vHx4SVT6Kg== X-Received: by 10.157.1.74 with SMTP id 68mr4436413otu.62.1484220932138; Thu, 12 Jan 2017 03:35:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.39.113 with SMTP id r104ls6039498ota.8.gmail; Thu, 12 Jan 2017 03:35:31 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr1265932ote.8.1484220931376; Thu, 12 Jan 2017 03:35:31 -0800 (PST) In-Reply-To: <2884ad60-bfb5-5275-bfd1-e741b22b962f@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:30515 Archived-At: ------=_Part_468_2126305148.1484220930768 Content-Type: multipart/alternative; boundary="----=_Part_469_77118346.1484220930769" ------=_Part_469_77118346.1484220930769 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Vincente On Thursday, January 12, 2017 at 8:45:08 PM UTC+13, Vicente J. Botet=20 Escriba wrote: > Le 11/01/2017 =C3=A0 21:49, gmis...@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= =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. >> > > 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 not= =20 > 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 enumeration.= =20 > The UB is defined in standard. See the paragraph I mentioned. What I'm=20 > saying is that we need a function that checks also exactly for the valid= =20 > values. Is that so complex to understand. > What made it complex to me was that you said UB and I didn't see any UB. Yes I agree we need a function to test the enum values. I do not know why= =20 you feel it's 'subset' of enum values though. =20 > > =20 > >> 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= =20 >> 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= =20 >> has effectively canonized it, so there it is. Alternatively, you may be= =20 >> using that enum as a bitfield. >> >> The thing is, that is a solved problem: get the underlying type with=20 >> `std::underlying_type_t`. That, and its corresponding `numeric_limits= `=20 >> will tell you everything you need to know about the range of that=20 >> enumeration. >> >> I don't want to solve problems that are already solved. We don't need an= y=20 >> modification on the compiler to solve this case, but if it solve the mor= e=20 >> dificult case it could solve this as well. >> > > What are you both referring to here?=20 > > 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 meta-programming= =20 > 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 reflectio= n=20 > proposal has, yes. > > Or maybe you are talking about modifying the language (so still a compile= r=20 > 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= =20 >> to know if a particular integer (which does not match any enumerator) is= =20 >> within the valid range for that enum? >> >> Because this is legal. I can assign it a value on the specified range.= =20 >> That's all. If I want my code to be outside the UB world I should be abl= e=20 >> to check on the conditions. I can of course do it for each particular ca= se,=20 >> but what we are talking of here is about what the compiler could do for = us=20 >> 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=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. >> >> >> If you don't have a problem to be solved with such a function, then=20 >> 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 hav= e=20 >>> 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=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? >> > > I had std::any_enum_value in my earlier post and make_bad_enum knew the= =20 > 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 he= re? > > It seems that I should not explain myself correctly as people is not=20 > understanding the complementary problem I'm raising. > sorry=20 > > The question is : Does your any_enum_value check for the enumerators=20 > values or the valid range of the enumeration? > My std::any_enum_value does not range check or anything, I envisaged it as= =20 a container that promises to be large enough to hold any enum=20 value possible for an ABI, nothing else. As best as I can tell from looking= =20 at my earlier post, any_enum_value was left in by mistake from a more=20 complex design where I was thinking where the interface would be more like= =20 std::optional. But I didn't recommend that design in the end so I don't think it was used= =20 because bad_enum isn't used either, I used std::range_error and satisfied= =20 myself that was ok because the error message would be detailed enough to=20 show what type of enum failed and the value that failed to convert. So=20 a dedicated bad_enum wasn't needed unless we needed to query information=20 out of that. Which I decided we probably didn't. Hope that helps. --=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/d2c589d7-15a3-4069-b32e-7b6506438ca7%40isocpp.or= g. ------=_Part_469_77118346.1484220930769 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Vincente

On Thursday, Januar= y 12, 2017 at 8:45:08 PM UTC+13, Vicente J. Botet Escriba wrote:
=20 =20 =20
Le 11/01/2017 =C3=A0 21:49, gmis...@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.

What made it complex to me was that= you said UB and I didn't see any UB.
Yes I agree we need a f= unction to test the=C2=A0enum values. I do not know=C2=A0why you feel=C2=A0= it's =C2=A0'subset' of enum values though.
=C2=A0

=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 outsid= e 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 i= t 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.

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 kn= ow 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 se= e 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 thi= s conversation 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.
sorry=C2=A0

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

My std::any_enum_value does not range check or=C2=A0anythi= ng, I=C2=A0envisaged it as a container that promises to be large enough to = hold any enum value=C2=A0possible for an ABI,=C2=A0nothing else. As=C2=A0be= st as I can tell from looking at my earlier post,=C2=A0any_enum_value=C2=A0= was left in by mistake=C2=A0from a=C2=A0more complex design=C2=A0where I wa= s thinking where the interface would be more like std::optional.
=
But I didn't=C2=A0recommend that design in the end=C2=A0= so I don't think=C2=A0it was used because bad_enum=C2=A0isn't used = either, I used std::range_error and satisfied myself that was ok because th= e error message would be detailed enough to show what type of enum failed a= nd the value that failed to convert.=C2=A0So a=C2=A0dedicated bad_enum wasn= 't needed unless we needed to query information out of that. Which I de= cided we probably didn't.

Hope that helps.
=
=20

--
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/d2c589d7-15a3-4069-b32e-7b6506438ca7= %40isocpp.org.
------=_Part_469_77118346.1484220930769-- ------=_Part_468_2126305148.1484220930768-- .