220 30472 <1841091b-9f97-4724-9f95-3193c0fb94fb@isocpp.org> 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: Tue, 10 Jan 2017 15:06:56 -0800 (PST) Lines: 544 Approved: news@gmane.org Message-ID: <1841091b-9f97-4724-9f95-3193c0fb94fb@isocpp.org> References: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> <24e58aad-ecbc-4c83-a21b-de56ea4c1db0@isocpp.org> <040e99e3-8f07-409f-3a47-ebdfb2bfb465@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1712_1528224376.1484089616543" X-Trace: blaine.gmane.org 1484089640 2706 195.159.176.226 (10 Jan 2017 23:07:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2017 23:07:20 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBEOS2XBQKGQE3JNYXKY@isocpp.org Wed Jan 11 00:07:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cR5VF-0006pz-ND for gclcip-std-proposals@m.gmane.org; Wed, 11 Jan 2017 00:06:54 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id j94sf177467833uad.0 for ; Tue, 10 Jan 2017 15:06:58 -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=/iNTiNDxAIl18ux0NfW1HcFw698zyeiFrv3pkTJcqzE=; b=gRvvFhPID+ff+oKFaX4qtfXybFoneAFnZmt3Jk19pAf+LdsSDO1AY4SRajQd5zuliD 9HXp4DhSxvH0KSWqAd6jelPViu7KWKGd4wyLNDlD+Y2vBrwqqPJ1O3mHFOiJbt4alN5j T1DJNCMS7h8pzXzUshnV941P2qYrmWxv/iPTs01yEZ9TATJO9KF4fFi4zMYGdXImi1Q+ e2k4HIuw9jrssXj4QHWcMDzACLaKngLZrNbaBNMNV08N6G8oNmvVef6yfvbyuyyU+O5G f+Z/oQojiejp9HQxa2s/Fgdb5AoI/veHLfS4F/rB4XiOh9pN4wbzyiLjdl1x0CFwYd/p Y0EA== 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=/iNTiNDxAIl18ux0NfW1HcFw698zyeiFrv3pkTJcqzE=; b=RGRNdN2d/3/0fddL5xKHNcf3fU9KLA/DRnA1Fq1WrEXuOyZr0saiQiwwKs0mcdtsT0 ZLj5tMQYKYRN7Va1rRauJbj5RW4EWXPNKA2xbAaqEw8E13Ymr7a0sjbloo8wHhnGTI7H VFR2iX378mhJlYwP5dip2o/Mx0xJLm+8MfWT4v8h6A7XW/XO2r5gREkRJm6FVGjNtB2W SUl/bVO7aA+GQ+7Kz7EN8iSmS8E11r2ZnazOD/vvI3zMfDfhh1oQ5gx2q8KGVfUBVjKP Iwmw6UpIua+LS+oI+wAkrASVxoHqrqtIXn6rUCmX6jcpUYx+1LfIRr8wLK3IT/R0rIPy TOdw== 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=/iNTiNDxAIl18ux0NfW1HcFw698zyeiFrv3pkTJcqzE=; b=idN8BjDyIuwxXqOi7mnTWgVdFwA7ECtOV1+fDbl6tKY6JI0NOQuIWzfMsievv9J9qM rCGhDV/xFohkjBnvVz7X3/L71z7Hx2Fac9dYRQ9y95ZB812ZaeZbX2XRtZsKqmu+jRwV d07p+PNZqoilmuX0LbEkyAdj4hR2zCfzDADE/0TOCgFbZKFm6Kq7VZSO8w39jVgy5I3Y GblvEEmsoy0CZTPz8/dGgkFVxK8rFmkF/uFWDDmzS0DGopmWvro7gIahaDlpfHU8G74g MVU4ZnBQEW9lFTAuq9+FZdpTtO2Fl72ur/WBhpKaXujZzZCw/lSK1CcVwExLFrz/AZ0b U+qQ== X-Gm-Message-State: AIkVDXIZlOmliHiAb7Pn4p8783YvdU7wdMjUmakfJ9uotbXB8fi8TPg6Pqr0Ljt6Hor0Sw== X-Received: by 10.31.1.6 with SMTP id 6mr1348176vkb.28.1484089617911; Tue, 10 Jan 2017 15:06:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.8 with SMTP id m8ls2710858otm.43.gmail; Tue, 10 Jan 2017 15:06:57 -0800 (PST) X-Received: by 10.157.41.149 with SMTP id n21mr502404otb.4.1484089617061; Tue, 10 Jan 2017 15:06:57 -0800 (PST) In-Reply-To: <040e99e3-8f07-409f-3a47-ebdfb2bfb465@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:30472 Archived-At: ------=_Part_1712_1528224376.1484089616543 Content-Type: multipart/alternative; boundary="----=_Part_1713_2094802392.1484089616544" ------=_Part_1713_2094802392.1484089616544 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, January 10, 2017 at 5:26:11 PM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > Le 10/01/2017 =C3=A0 20:30, Nicol Bolas a =C3=A9crit : > > On Tuesday, January 10, 2017 at 1:49:05 PM UTC-5, Vicente J. Botet Escrib= a=20 > wrote:=20 >> >> Le 10/01/2017 =C3=A0 16:31, m.ce...@gmail.com a =C3=A9crit : >> >> >> W dniu wtorek, 10 stycznia 2017 13:49:00 UTC+1 u=C5=BCytkownik=20 >> gmis...@gmail.com napisa=C5=82:=20 >>> >>> >>> >>> On Tuesday, January 3, 2017 at 10:56:05 PM UTC+13, m.ce...@gmail.com=20 >>> wrote:=20 >>>> >>>> Hi,=20 >>>> >>>> >> I'll try to create a first draft after I get some more comments w.r.t to= =20 >> exceptions. >> For sure baseline API must be exception-free. >> Do we really want to additionally support API that throws on error? >> I'm rather inclined to leave it out - similarly as in to_chars/from_char= s. >> =20 >> >>> >>> I hope this post assists you with your proposal. My suggestions are for= =20 >>> your proposal to look something like this: >>> >>> In I think add: >>> >>> bool template is_enum( V ev ) >>> { >>> // compiler magic: >>> // Calling this routine causes the compiler to generate or a call a=20 >>> routine >>> // that returns true if the value ev matches one of the enum E's >>> // values. otherwise false. >>> } >>> >> >> 'is_enum' name is already used in type_traits header. >> Also is_enum seems redundant to me, since to_enum already reports >> if convertion succeeded instead of: >> if (is_enum(139)) >> >> you could write: >> if (to_enum(139).is_valid) >> >> or even: >> if (to_enum(139)) >> if we add explicit bool convertion operator for to_enum_result. >> >> >> I believe we need two checking functions: >> * is_enumerator : checks if the explicit conversion from the integer is= =20 >> one of the explicit enumerators >> * is_in_enum_range: checks if the integer is in the range of valid=20 >> values. This is the precondition of the static_cast. >> >> IIUC when the underlying type is explicit, the range of values are the= =20 >> range of the underlying type. However when the underlying type is implic= it=20 >> the range goes from the min to the max of the values of the enumerators. >> > > Right, but `is_enumerator` is a functional superset of `is_in_enum_range`= ..=20 > Do people really need to ask *only* if a value is in the range of an=20 > enumerator? > > I don't follow you. You surely wanted to say subset > Yes, I did. My mistake. =20 > > The standard says in 7.2/8 :=20 > > > 1.=20 > =20 > 8 For an enumeration whose underlying type is fixed, the values of=20 > the enumeration are the values of the underlying type. Otherwise, for = an=20 > enumeration where emin is the smallest enumerator and emax is the=20 > largest, the values of the enumeration are the values in the range bmi= n=20 > to bmax, defined as follows: Let K be 1 for a two=E2=80=99s complement= =20 > representation and 0 for a ones=E2=80=99 complement or sign-magnitude= =20 > representation. bmax is the smallest value greater than or equal to ma= x > (|emin| =E2=88=92 K, |emax|) and equal to 2M =E2=88=92 1, where M is a= non-negative=20 > integer. bmin is zero if emin is non-negative and =E2=88=92(bmax + K) = otherwise.=20 > The size of the smallest bit-field large enough to hold all the values= of=20 > the enumeration type is max(M,1) if bmin is zero and M + 1 otherwise. = *It=20 > is possible to define an enumeration that has values not defined by an= y of=20 > its enumerators.* If the enumerator-list is empty, the values of the= =20 > enumeration are as if the enumeration had a single enumerator with val= ue 0.=20 > =20 > > For me enumerators are any one of the named enum values. This set is a=20 > subset not a superset of the range of valid values. > > As I said, until we don't have enums that consists only of the=20 > enumerators, there would be always the need to check if a value is a vali= d=20 > value for the enumeration. > =20 > We could define a class that accepts only the enumerators as valid values,= =20 > but the language enums can accept more values. > This is way I believe that the two checks are needed. > Here's the thing. There are enumerations that have a fixed underlying type (`enum class`es=20 use `int` by default), and there are enumerations that have an implied=20 underlying type (ie: non-`class` enums without a specified type). The question I have to ask is this: if you have an integer, why do you need= =20 to know if it will fit within the range of an enum with an implied=20 underlying type? What problem are you trying to solve? What code are you=20 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. I= =20 personally despise this obvious abuse of a language feature, but C++17 has= =20 effectively canonized it, so there it is. Alternatively, you may be using= =20 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. But if the enum has an implied underlying type, then why would you need to= =20 know if a particular integer (which does not match any enumerator) is=20 within the valid range for that enum? What are you trying to do that you=20 need to do this? If you don't have a problem to be solved with such a function, then there's= =20 really no point in adding one. I don't know why the new C++11 enum with an explicit underlying type have a= =20 > different range of valid values. > I'll be interested in knowing the rationale. > Because enums are integers. That's the rationale. --=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/1841091b-9f97-4724-9f95-3193c0fb94fb%40isocpp.or= g. ------=_Part_1713_2094802392.1484089616544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, January 10, 2017 at 5:26:11 PM UTC-5, Vicente = J. Botet Escriba wrote:
=20 =20 =20
Le 10/01/2017 =C3=A0 20:30, Nicol Bolas a =C3=A9crit=C2=A0:
On Tuesday, January 10, 2017 at 1:49:05 PM UTC-5, Vi= cente J. Botet Escriba wrote:
Le 10/01/2017 =C3=A0 16:31, m.ce...@gm= ail.com a =C3=A9crit=C2=A0:

W dniu wtorek, 10 stycznia 2017 13:49:00 UTC+1 u=C5=BCytkownik gmis...@gmail.com napisa=C5=82:


On Tuesday, January 3, 2017 at 10:56:05 PM UTC+13, m= ..ce...@gmail.com wrote:
Hi,


I'll try to create a first draft after I get some more comments w.r.t to exceptions.
For sure baseline API must be exception-free.
Do we really want to additionally support API that throws on error?
I'm rather inclined to leave it out - similarly as in to_chars/from_chars.
=C2=A0

I hope this post assists you with your proposal.=C2=A0My suggestions are for your proposal t= o look something like this:

In <utility> I think add:

bool template<typename E, typename V> is_enum( V ev )
{
=C2=A0// compiler=C2=A0magic:
=C2=A0// Calling this routine causes the compiler = to generate or a call a routine
=C2=A0// that returns true if the value ev matches one of the enum E's
=C2=A0// values. otherwise false.
}

'is_enum' name is already used in type_traits header.
Also is_enum seems redundant to me, since to_enum already reports
if convertion succeeded instead of:
if (is_enum<MyEnum>(139))

you could write:
if (to_enum<MyEnum>(139).is_valid)

or even:
if (to_enum<MyEnum>(139))
if we add explicit bool convertion operator for to_enum_result.


I believe we need two checking functions:
* is_enumerator : checks if the explicit conversion from the integer is one of the explicit enumerators
* is_in_enum_range: checks if the integer is in the range of valid values. This is the precondition of the static_cast.

IIUC when the underlying type is explicit, the range of values are the range of the underlying type. However when the underlying type is implicit the range goes from the min to the max of the values of the enumerators.

Right, but `is_enumerator` is a functional superset of `is_in_enum_range`. Do people really need to ask only if a value is in the range of an enumerator?
I don't follow you. You surely wanted to say subset

Yes, I did. My mistake.
=C2=A0

The standard says in 7.2/8 :
=20

  1. 8 =C2=A0For an enumeration whose un= derlying type is fixed, the values of the enumeration are the values of the underlying type. Otherwise, for an enumeration where emin = is the smallest enumerator and emax is the largest, the values of the enumeration are the values in the range bmin to bmax, defined as fol= lows: Let K be 1 for a two=E2=80=99s complement representation and 0 for a ones=E2=80=99 complement or sign-magnitude representation. bmax is the smal= lest value greater than or equal to max(|emin| =E2=88=92 K, |emax|) and equal to 2M =E2=88=92 1, where M is a non-negative integer. bmin is zero if emin is non-negative and =E2=88=92(bmax + K) otherwise. The size of the smallest bit-field large enough to hold all the values of the enumeration type is max(<= span style=3D"font-size:10.000000pt;font-family:'LMMathItalic10'">M= ,1) if bmin is zero and M + 1 otherwise. It is possible to define an enumeration that has values not defined by any of its enumerators. If the enumerato= r-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0.

=20
For me enumerators are any one of the named enum values. This set is a subset=C2=A0 not a superset of the range of valid values.

As I said, until we don't have enums that consists only of the enumerators, there would be always the need to check if a value is a valid value for the enumeration.
=C2=A0
=20 We could define a class that accepts only the enumerators as valid values, but the language enums can accept more values.
This is way I believe that the two checks are needed.

Here's the thing.

There are enumerations that have= a fixed underlying type (`enum class`es use `int` by default), and there a= re enumerations that have an implied underlying type (ie: non-`class` enums= without a specified type).

The question I have to ask is this: if y= ou have an integer, why do you need to know if it will fit within the range= of an enum with an implied underlying type? What problem are you trying to= solve? What code are you trying to write?

If the enum has a fixed u= nderlying type, then you might need to know the range because you're us= ing the enum as an ad-hoc strongly typed integer. I personally despise this= obvious abuse of a language feature, but C++17 has effectively canonized i= t, 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 wit= h `std::underlying_type_t<E>`. That, and its corresponding `numeric_l= imits` will tell you everything you need to know about the range of that en= umeration.

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 en= umerator) is within the valid range for that enum? What are you trying to d= o that you need to do this?

If you don't have a problem to be so= lved with such a function, then there's really no point in adding one.<= br>
=20 I don't know why the new C++11 enum with an explicit underlying typ= e have a different range of valid values.
I'll be interested in knowing the rationale.
=

Because enums are integers. That's the rationale.

--
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/1841091b-9f97-4724-9f95-3193c0fb94fb= %40isocpp.org.
------=_Part_1713_2094802392.1484089616544-- ------=_Part_1712_1528224376.1484089616543-- .