220 30457 article Path: news.gmane.org!.POSTED!not-for-mail From: m.cencora@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: enum_cast proposal Date: Tue, 10 Jan 2017 07:31:07 -0800 (PST) Lines: 530 Approved: news@gmane.org Message-ID: References: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1640_282778673.1484062268061" X-Trace: blaine.gmane.org 1484062284 17202 195.159.176.226 (10 Jan 2017 15:31:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2017 15:31:24 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD7YFUMJRYMBBPH42PBQKGQE6X5VLVA@isocpp.org Tue Jan 10 16:31:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQyO9-00035m-Ab for gclcip-std-proposals@m.gmane.org; Tue, 10 Jan 2017 16:31:05 +0100 Original-Received: by mail-yw0-f200.google.com with SMTP id q71sf117544894ywg.1 for ; Tue, 10 Jan 2017 07:31:10 -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=2zC9atiLjcqoLBIGtYwMbuYsymPNVopdgVbN7NtGR2E=; b=YiBuXcnjGcWp/8XfB1T5gQRvZhUH6mfpeSFfIH6XdoygLucBFT1TUW+jIkIO/gJfzF 2BR59+XGZt9/Oqu4Ql87qE7dh4ADDD7qVZSF5voMCTIYKs7hB+MOUCObmRdkVboYU0u8 v7ckxpNhP1q2XtTse5rgLT7wmr4RneIwkieGK+z0DTCiRKx6UW4D1gm/qTkL2/bki4Mk zil1FQ5mXKyKhgrDMn9Jogk9O5kos57My3WcCl2E691o6ht9645O/vEIdx5fe8/c6OBo KRbBwfy7x9K32v/L+UiTOtX+ux6jK1CaEl1ryHf7ftx2qnrOnTdqOd48XyD+VoCSnb0J 9VXw== 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=2zC9atiLjcqoLBIGtYwMbuYsymPNVopdgVbN7NtGR2E=; b=OWZmaEqIJEL5XWyqt3DVOn+Lxzh7RsMk/KAunCCiHsxaRNZUvMmeRc0Jrp0oirjG8e Zi0d0ZsU2HNDYLkGCU61CTq7bYyPIBChMofzERPoUw1D8JMiBGXmMDiezlPfuSvwzV5a Ps7AVXJPNnTVqgCNaiwuHse6GH6f/hEZapvxNi7wDvgXysbYIRDL01E3zXXNiloNjNva FjTs/NHH3W7/hcEce3MLtS6+Y6/Jy4b+4azOkqom22svqS8B1F4xwzQWm1ydpX6ClwI7 nzNoeftOmZ9eROKNMm37fnLb66WCTne19GE7Fg3z7j5HysXeGLgi5SHZEcszdkhF1fk2 V24w== 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=2zC9atiLjcqoLBIGtYwMbuYsymPNVopdgVbN7NtGR2E=; b=P69G5inbyebKwzhS2eMZV3eWQcsNvz6AwSbJhHG/5i+Khb/SsTY42mI/gqKJLT42sO p0CD7/CIv8DTwn1KdQedeDaK4UqwqFQ8DMYoiwc2Rf7bQZhLrGYlrrjChrfRH0syrZ7j rhF7aEChNEnI+z1DByBL8VePpILPwNF0D7GqajSsT2d3N/AG5kKFAduNCqdB40pJPovz 8Lw88qcAWUhQ5Hz2j+U6b/g1fdemtVvkgBPHjH5wcTMJekLgjmbEQWkGtRY6heGwR32Q vaw7Dg/gYACuTZR9iohLTlxszNxEn9jfS9McdNmr2IU4xrYdGhygKUzXviKnhIRGWUUi Ar0g== X-Gm-Message-State: AIkVDXIyOoF/VCaHYJdL3VKy3Tz/J7rOuVRdefWQkC1SeWZyltd5p+vdKF7H3+bFeaCAqg== X-Received: by 10.99.178.82 with SMTP id t18mr1243778pgo.45.1484062269540; Tue, 10 Jan 2017 07:31:09 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.41.177 with SMTP id n46ls1536569otb.37.gmail; Tue, 10 Jan 2017 07:31:08 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr216919ote.8.1484062268522; Tue, 10 Jan 2017 07:31:08 -0800 (PST) In-Reply-To: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> X-Original-Sender: m.cencora@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:30457 Archived-At: ------=_Part_1640_282778673.1484062268061 Content-Type: multipart/alternative; boundary="----=_Part_1641_1102541637.1484062268062" ------=_Part_1641_1102541637.1484062268062 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu wtorek, 10 stycznia 2017 13:49:00 UTC+1 u=C5=BCytkownik gmis...@gmai= l.com=20 napisa=C5=82: > > > > On Tuesday, January 3, 2017 at 10:56:05 PM UTC+13, m.ce...@gmail.com=20 > wrote: >> >> Hi, >> >> I propose to add a enum_cast function that safely casts int value to a= =20 >> target enum type if int value represents a valid enumerator. >> >> template >> optional enum_cast(Int value); >> >> requires: is_enum, is_integral >> >> enum color >> { >> red =3D 1, >> green =3D 200, >> blue =3D 3 >> }; >> >> static_assert(enum_cast(200u) =3D=3D color::green); >> static_assert(enum_cast(3) =3D=3D color::blue); >> static_assert(enum_cast(4) =3D=3D nullopt); >> >> >> This should work for both scoped and unscoped enums. >> For opaque enums this would only check if value fits in underlying type. >> >> Why do we want this: >> - validation of input data (e.g. coming from user or deserialization). >> - other? >> >> I know this could be purely library extension if based on reflection, bu= t=20 >> since we don't know when we will get reflection, >> and implementation based on reflection may not be optimal, >> I think it should be implemented with compiler support (i.e. via=20 >> __builtin_* intrinsic). >> >> Regards, >> Maciej >> > > > I was thinking some more about this proposal. I really think the=20 > functionality you suggest is a good idea. > I hope you proceed with a proposal. If you decide not to let me know. > 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_chars. =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. > // Users call this routine to convert an integer to an enum. > They call this if they aren't sure about their conversion data > // and don't mind exceptions and want simple like std::to_string > // They might expect such a function to be present. > // Though to be fair I'm not sure we should encourage this? > // They should get good error messages. > template E to_enum_or_throw(V ev) > { > if (is_enum(ev)) > return static_cast(ev); > throw make_bad_enum(ev);=20 > } > > template class to_enum_result > { > public: > E enum_value; > bool is_valid; > }; > > // Call this if you can't use/afford exceptions. It seems optimal? > template to_enum_result to_enum( V ev ) noexce= pt > { > if (is_enum(ev)) > return to_enum_result{true,static_cast(ev)}; > return to_enum_result{false, E{}}; > } > > // if is_valid returns false after to_enum, the user can use these=20 > routines to get good error > // messages / report how they wish when they wish: > As there is only one possible reason why the to_enum failed (integer didn't match any enumerator of target enumeration type)=20 I see no reason for following functions and classes. > // Some type that holds the largest enum value ever possible. > using std::any_enum_value =3D unspecified; > > class bad_enum > { > public: > std::any_any_enum_value bad_enum_value; > std::string enum_type_name; > }; > =20 > template std::bad_enum make_bad_enum(V ev) > { > // Use some compiler magic to get the name of the name of the enum type = E. > // Use it to construct a message like: > // '{ev}' is not a legal value for an enum of type '{E}' > return std::range_error(msg); > } > > > Note in all methods: > * constrain E to only be an enum or enum class type. > * constrain V to only accept integral types. > > Observations > ------------ > > * is_enum() is there for people who just need to check validity and no=20 > more. > and saves the user writing redudant boiler plate code that the compiler= =20 > does better. > * to_enum_or_throw() is there for people who find simple works for them. > its name makes it clear that exceptions can happen. > * to_enum() is there for people who need performance and without=20 > exceptions. > =20 > * We don't depend on optional.=20 > * Means isn't dependent on optional if we put it there. > * make_bad_enum avoids making bad_enum a template. > * make_bad_enum gives us good error messages and better than=20 > bad_optional_access. > * make_bad_enum means we can create an error class for reporting elsewher= e=20 > - we don't have to throw it. > * make_bad_enum means we don't expose any get enum_type_name function the= =20 > reflection people will reproduce. > * make_bad_enum gives people flexibility to throw when they are ready=20 > instead of forcing a throw as soon as conversion fails. > * Might play well with structured bindings. > =20 > Main choices: > * We could model this on optional i.e. include has_value etc. but it seem= s=20 > simpler not to. Either way is fine to me. > I'm not sure such safety is warranted and from_chars/to_chars is pretty= =20 > simple too so I went that way. > As committee already stated their preference in from_chars/to_chars case,= =20 consider me convinced. I will use 'to_enum_result' in draft. Also I'll use 'to_enum' as function name to match 'to_chars' convention. =20 > * The caller has all the utilities here to build that or work=20 > with optional directly - whatever they need. > * I think being able to get good error messages on failure is important. > This tries to enable making decent errors available no matter what method= =20 > or is used. > i.e. include the enum type name and bad value in the error.=20 > * I've used std::range_error as the exception type for failure but another= =20 > may be appropriate. > bad_enum as an exception type contains the value that was bad and the typ= e=20 > name that it failed to convert to. > This would allow people to extract the values to construct their own erro= r=20 > messages (perhaps in other languages like French etc.). > > If std::bad_enum is too much API, that could be dropped for just=20 > std::range_error or something as long a it contains > a full description of the error I think that's fine. > > I'd like to know what you and the Committee's disposition towards these= =20 > ideas and views. Hope this helps. > Thanks for your valuable input. Regards, Maciej =20 > > Thanks > GM > --=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/a35d9f20-9e4f-4789-b7e5-5cb08f99e6bd%40isocpp.or= g. ------=_Part_1641_1102541637.1484062268062 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

W dniu wtorek, 10 stycznia 2017 13:49:00 UTC+1 u=C5=BC= ytkownik 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 propose to add a enum_cast function that safely c= asts int value to a target enum type if int value represents a valid enumer= ator.

template <typena= me Enum, typena= me Int>
optional<Enum> = enum_cast(Int value);

requires: is_enum<Enum>,= is_integral<Int>

enum color
{
=C2=A0 =C2=A0red =3D= 1,
=C2=A0 =C2=A0gr= een =3D 200,<= br>=C2=A0 =C2=A0blue =3D= 3
};

<= span style=3D"color:rgb(0,0,136)">static_assert(enum_cast<color>(200u) =3D=3D color::green);=
static_assert(enum_cast<color>(3) =3D=3D color= ::blue);
sta= tic_assert(enum_cast&l= t;color>(4= ) =3D=3D nullopt);


This should work for= both scoped and unscoped enums.
For opaque enums this would only= check if value fits in underlying type.

Why d= o we want this:
=C2=A0- validation of input data (e.g. coming= from user or deserialization).
=C2=A0- other?

I know this could be purely library extension if based on reflection= , but since we don't know when we will get reflection,
and im= plementation based on reflection may not be optimal,
I think it s= hould be implemented with compiler support (i.e. via __builtin_* intrinsic)= ..

Regards,
Maciej


I was thinking some more about this pr= oposal. I really think the functionality you suggest=C2=A0is a good idea.
I hope you proceed with a proposal.=C2=A0If you decide not to let = me know.

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
<= div>
I hope this post assists you with your proposal.=C2=A0My= suggestions are for your proposal to look something like this:
<= br>
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 ca= uses the compiler to generate or a call a routine
=C2=A0// that r= eturns 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 repo= rts
if convertion succeeded instead of:
<= div class=3D"subprettyprint">if (is_enum= <MyEnum>(139))

<= div>you could write:
= if (to_enum<MyEnum>(139).= is_valid)<= /span>

or even:
if (to_enum<= span style=3D"color: #660;" class=3D"styled-by-prettify"><MyEnum>(139))
if we add ex= plicit bool convertion operator for to_enum_result.


<= div>
// Users call this routine to convert an integer to an e= num.
They call this if they=C2=A0aren't sure about=C2=A0their= conversion data
// and don't mind exceptions and want simple= like std::to_string
// They might expect such a function to be p= resent.
// Though to be fair I'm not sure we should encourage= this?
//=C2=A0They should get good error messages.
tem= plate<typename E, typename V> E to_enum_or_throw(V ev)
{
=C2=A0if (is_enum<E>(ev))
=C2=A0=C2=A0return static= _cast<E>(ev);
=C2=A0throw make_bad_enum<E,V>(ev);=C2= =A0
}

template<typename E> cl= ass to_enum_result
{
public:
=C2=A0E enum_val= ue;
=C2=A0bool is_valid;
};

<= div>// Call this if you can't use/afford exceptions. It seems optimal?<= /div>
template<typename E, typename V> to_enum_result<E> to= _enum( V ev ) noexcept
{
=C2=A0 if (is_enum<E, V>= (ev))
=C2=A0=C2=A0=C2=A0 return to_enum_result<E>{true,stat= ic_cast<E>(ev)};
=C2=A0 return to_enum_result<E>= {false, E{}};
}

// if is_valid=C2=A0retu= rns false after to_enum, the user can use these routines to get good error<= /div>
// messages / report how they wish when they wish:

As there is only one possible reason why the = to_enum failed
(integer didn't match any enumerator of ta= rget enumeration type)=C2=A0
I see no reason for following functi= ons and classes.


// Some type that hol= ds the largest enum value ever possible.
using std::any_enum= _value =3D unspecified;

class bad_enum=
{
public:
=C2=A0=C2=A0=C2=A0std::any_any_enu= m_value bad_enum_value;
=C2=A0=C2=A0 std::string enum_type_name;<= br>};
=C2=A0
template<typename E, typename V> std::bad= _enum make_bad_enum(V ev)
{
=C2=A0// Use some compiler = magic to get the name of the name of the=C2=A0enum type=C2=A0E.
= =C2=A0// Use it to construct a message like:
=C2=A0// '{ev}&#= 39; is not a legal value for an enum of type '{E}'
=C2=A0= return std::range_error(msg);
}

=

Note in all methods:
* constrain= E to only be an enum or enum class type.
* constrain V to only a= ccept integral types.

Observations
------------

* is_enum() is there for people who = just need to check validity and no more.
and saves the user writi= ng redudant boiler plate code that the compiler does better.
* to= _enum_or_throw() is there for people who find simple works for them.
<= div>its name makes it clear that exceptions can happen.
* to_enum= () is there for people who need performance and without exceptions.
=C2=A0
* We don't depend on optional.=C2=A0
<= /div>
* Means <utility> isn't dependent on optional if we put= it there.
* make_bad_enum avoids making bad_enum a template= ..
* make_bad_enum gives us good error messages and better than bad_opt= ional_access.
*=C2=A0make_bad_enum means=C2=A0we can=C2=A0create = an=C2=A0error class=C2=A0for reporting elsewhere -=C2=A0we don't have t= o throw it.
*=C2=A0make_bad_enum means we don't expose any ge= t enum_type_name function the reflection people will reproduce.
*= make_bad_enum gives people flexibility to throw when they are ready instea= d of forcing a throw as soon as conversion fails.
* Might play we= ll with structured bindings.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">
Main choices:
*=C2=A0We could=C2=A0model this on optional=C2=A0= i.e. include=C2=A0has_value etc.=C2=A0but it=C2=A0seems simpler not to. Eit= her way is fine to me.
I'm not sure such safety is warranted = and=C2=A0from_chars/to_chars is pretty simple too so I went that way.
=

As committee already stated their pr= eference in from_chars/to_chars case, consider me convinced.
I wi= ll use 'to_enum_result' in draft.
Also I'll use '= to_enum' as function name to match 'to_chars' convention.
=
=C2=A0
* The=C2=A0caller has all the utilities here to build that or= work with=C2=A0optional directly -=C2=A0whatever=C2=A0they need.
* I think=C2=A0being able to get=C2=A0good error messages on failure is im= portant.
This tries to=C2=A0enable making decent errors available= no matter what method or=C2=A0is used.
=C2=A0i.e. include the en= um type name and bad value in the error.=C2=A0
* I= 9;ve=C2=A0used std::range_error as the exception type=C2=A0for failure but = another may be appropriate.
bad_enum as an exception=C2=A0type=C2= =A0contains the value that was bad and the type name that it failed to conv= ert to.
This=C2=A0would allow people to extract the values to con= struct their own error messages (perhaps in other languages like French etc= ..).

If std::bad_enum is too much API, that could b= e dropped for just std::range_error or something as long a it contains
a full description of the error I think that's fine.
<= /blockquote>
<= div>
I'd like to know what you and the=C2=A0Committee'= ;s disposition towards=C2=A0these ideas and views. Hope this helps.


Thanks for your va= luable input.

Regards,
Maciej
=C2=A0

Thanks
GM

--
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/a35d9f20-9e4f-4789-b7e5-5cb08f99e6bd= %40isocpp.org.
------=_Part_1641_1102541637.1484062268062-- ------=_Part_1640_282778673.1484062268061-- .