220 30471 <040e99e3-8f07-409f-3a47-ebdfb2bfb465@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: Tue, 10 Jan 2017 23:26:08 +0100 Lines: 526 Approved: news@gmane.org Message-ID: <040e99e3-8f07-409f-3a47-ebdfb2bfb465@wanadoo.fr> References: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> <24e58aad-ecbc-4c83-a21b-de56ea4c1db0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BF1F89400088942B4377F680" X-Trace: blaine.gmane.org 1484087185 29451 195.159.176.226 (10 Jan 2017 22:26:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2017 22:26:25 +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+bncBDH67CONY4PBBAV72XBQKGQE3JP4DOQ@isocpp.org Tue Jan 10 23:26:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cR4rm-0005jE-Uq for gclcip-std-proposals@m.gmane.org; Tue, 10 Jan 2017 23:26:07 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id h65sf29583024lfi.1 for ; Tue, 10 Jan 2017 14:26:11 -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=LERhjjdrlTR7hxRKHZZcTUCNlNkxawgjMhUlUDh5icE=; b=1sj15AbFI8hL4JLaHd+wliyXaXVCaLadtuDHT1dE8rcqAcAQ54moXWYbrCCBQQe6kX VbFPOI7t+64oHcvoRUaRv8Ob0t9+nz7E+D6/mZWNw6JkJjc4c0fWsR+yuZwMFOF8dZUg jRY5eHWpTpPvfMH+s4bIb4Uk23YFTKpK7SjPK1E6TrtSiXg4TQJeZGVF4KfxDvixwPKE syEmERJwXrMpYe53N8ReO9m0s+dQVR5m6kdoKy4BAELYj5nBLZZtC5swWWiGS6IFY4bP WzSUKMfFXQik2B+iI5/CcNcwUL1+kpTzEb9nNt3x+KIt6xd1zjZd/VXUyxxdrwI2hnrl dwUg== 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=LERhjjdrlTR7hxRKHZZcTUCNlNkxawgjMhUlUDh5icE=; b=P7JhrQ8EyhN3wOtTKAvtXX8dnEO94A417ZcVDyuYffyAEOR6s6PHF6Mk0xSEMKyDiV UbvWCnN7BN9/aYxl+NMqDJy9NWy2Af85W7o4DKVMh3tCr3cCeoNWIoxcFxBElYaMt2K0 1F4IyyxMHhSVtQqhl0h9YEI7JxL8Zy8gTVNUh6RIbQFCabtBDJFwqDt4uqYYZ5V0xviY YWdyDxchYYJ2QuHfcDiBaOPR4C2Q8s2UcEzEvgVrLCYDg78U5YQT9REW4/j3VSrL3fN8 +FbLa6J4njnOR+mJsXtgAZZzwTieSqvZvMkuRAgnEP6iss1rieLFJNVWiNJVofpb6FGe pScQ== X-Gm-Message-State: AIkVDXIYG2ofKj9ZPnAZTw6yY00lfhGJRS86L73H+A8A/NF2lc5Z21JUx8oDtPTIcL40yA== X-Received: by 10.46.83.78 with SMTP id t14mr502671ljd.26.1484087171389; Tue, 10 Jan 2017 14:26:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.69.202 with SMTP id l71ls476533wmi.27.gmail; Tue, 10 Jan 2017 14:26:10 -0800 (PST) X-Received: by 10.194.77.83 with SMTP id q19mr2957304wjw.186.1484087169997; Tue, 10 Jan 2017 14:26:09 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126]) by mx.google.com with ESMTPS id z80si3087462wmd.57.2017.01.10.14.26.09 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 10 Jan 2017 14:26:09 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.126; Original-Received: from imac-de-vicente-botet-escriba.home ([2.11.64.156]) by mwinf5d59 with ME id WmS81u00c3NGJZe03mS83g; Tue, 10 Jan 2017 23:26:09 +0100 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Tue, 10 Jan 2017 23:26:09 +0100 X-ME-IP: 2.11.64.156 In-Reply-To: <24e58aad-ecbc-4c83-a21b-de56ea4c1db0@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.126 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:30471 Archived-At: This is a multi-part message in MIME format. --------------BF1F89400088942B4377F680 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 > Escriba wrote: > > Le 10/01/2017 =C3=A0 16:31, m.ce...@gmail.com a =C3=A9c= rit : >> >> 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. >> >> >> I hope this post assists you with your proposal. My >> suggestions are for 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 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 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=20 > `is_in_enum_range`. Do people really need to ask /only/ if a value is=20 > in the range of an enumerator? I don't follow you. You surely wanted to say subset The standard says in 7.2/8 : 6. 8 For an enumeration whose underlying 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 follows: Let K be 1 for a two=E2=80=99s complement representation a= nd 0 for a ones=E2=80=99 complement or sign-magnitude representation. bm= ax is the smallest 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 inte= ger. bmin is zero if emin is non-negative and =E2=88=92(bmax + K) otherw= ise. The size of the smallest bit-field large enough to hold all the values of the enumeration type is max(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 enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0. C++ International Standa 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=20 valid value for the enumeration. We could define a class that accepts only the enumerators as valid=20 values, but the language enums can accept more values. This is way I believe that the two checks are needed. I don't know why the new C++11 enum with an explicit underlying type=20 have a different range of valid values. I'll be interested in knowing the rationale. 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/040e99e3-8f07-409f-3a47-ebdfb2bfb465%40wanadoo.f= r. --------------BF1F89400088942B4377F680 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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, Vicente J. Botet Escriba wrote:
Le 10/01/2017 =C3=A0 16:31, m.ce...@= gmail.com a =C3=A9crit=C2=A0:

W dniu wtorek, 10 stycznia 2017 13:49:00 UTC+1 u=C5=BCytkownik gmis...@gmail.c= om 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

The standard says in 7.2/8 :

  1. 8 =C2=A0= For an enumeration whose underlying 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 follows: 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 smallest value greater than or equal to max<= span style=3D"font-size: 10.000000pt; font-family: 'LMRoman10'">(|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(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 enumerator-list is empty, the values of the enumeration are as if the enumeration had a single enumerator with value 0.

C++ International Standa
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.

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.

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.

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/040e99e3-8f07-409f-3a47-ebdfb2bfb465= %40wanadoo.fr.
--------------BF1F89400088942B4377F680-- .