220 30455 <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: enum_cast proposal Date: Tue, 10 Jan 2017 04:48:59 -0800 (PST) Lines: 368 Approved: news@gmane.org Message-ID: <57258435-5d82-48e7-8ed7-3c38682418fb@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2523_1149900171.1484052539792" X-Trace: blaine.gmane.org 1484052551 16442 195.159.176.226 (10 Jan 2017 12:49:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2017 12:49:11 +0000 (UTC) Cc: m.cencora@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBPNQ2PBQKGQEACN3WMQ@isocpp.org Tue Jan 10 13:49:05 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQvrF-0002eD-Lo for gclcip-std-proposals@m.gmane.org; Tue, 10 Jan 2017 13:48:57 +0100 Original-Received: by mail-yb0-f199.google.com with SMTP id 186sf561135725yby.5 for ; Tue, 10 Jan 2017 04:49:02 -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=qHzP+OIgcra2BWFKfAURf8fq8FiWWVWWPu+VNpG6SMQ=; b=I68b0aIiObPv7SpIFMU+ihEg1KvAlOOBn2uTrbOrPgXnnrGRtIyH8iR9w6G11fv2N3 LPc5yTARRmLXwGYS8GeNlv+UNz+uuTCJSXGWnmZGTSPxJ++FOt6CcT7SGHpbO3DlDBT8 65qGwU3o06koxzYDx/enTez/Pzb0RdzVKb986o8IteSg45WxfPqfcxwE9bgg4MuAvc2c h3Dsb9xOE98+TzQZ/yPYXSYbI0W1qoR2PrQiA+qnLMrk6YwHbypFroMKbUU97gGwX+SC rVgHLGefgjE0DZ3rYslpy1vB0fxph7bOAvzVrHTVGm9q+npD7o/BKXoNqUrhZo7cCIUE 0R1Q== 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=qHzP+OIgcra2BWFKfAURf8fq8FiWWVWWPu+VNpG6SMQ=; b=UFjUs3LNEkvfPVLP6k1O3LaGaWZeZJat4QeN/DbhIpZFYuEiS4woBs61mzOQwKCb8w /2T1d5RRQVFaVDshm1O0YAlCIhOSL+B8iV3bjEMXUQFKuIVdoiM/bfXF365sjspFUZPK ouCo0qua32cwIm/3PyiQEKoWjQDHclxjRIOkmIaivD9LB6SIjByF9RJ57WCxzaXmHE7F Whg4jkAU44FtQYvhWCX0NU5jbfkRgdUnBOMZBPfQUJexCLiNdvbYJcIXPCMnx0YFtD1q +8DAHHlv6ED2WIAbZJtrF19M4dCKf9dze1L8VTyjc7yT617KHr+zCeumGV7jGHO9rhIu AgRA== 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=qHzP+OIgcra2BWFKfAURf8fq8FiWWVWWPu+VNpG6SMQ=; b=F7wxT2yP1K7cEraDLtP0IRlg7J+eKsgpV7YRtfhyPGppiGJYcrqn0B5BczU/zVb/BE O2830Qk0FMssRNP38F6aB1IfYMCi/3mg9igYxg9Z2VkMJlEkULa5CiIlgIEvFfePNCq8 AUgsmVCPCoT9Pwo5HZahORx9Kv6rzy0/QXuYt8YkpYVtl15r6e3Qa0Qj2774xoenr9N0 qE2fP0ezklI8Px3bQqtKBN7LnyuROs1D3wIMnnm+WFBB+i6lYnkapB7E10dUKNilQxHZ hj0wee3N9HpGyLzOe3+PRK/LPUp1TTh5aV1PTRVK7Y6RT759UQ99wIpnXtRT+OSbzHl9 6mDg== X-Gm-Message-State: AIkVDXLGregCXOA7+ZuDEA8ejNbVTdERl13KhG7V8fuMz/1QKA7L+7Wsl6jKM2iF7h0ECw== X-Received: by 10.13.196.133 with SMTP id g127mr897317ywd.153.1484052541853; Tue, 10 Jan 2017 04:49:01 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.18.211 with SMTP id g77ls1249612otg.39.gmail; Tue, 10 Jan 2017 04:49:01 -0800 (PST) X-Received: by 10.157.8.10 with SMTP id 10mr106744oty.19.1484052541064; Tue, 10 Jan 2017 04:49:01 -0800 (PST) In-Reply-To: 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:30455 Archived-At: ------=_Part_2523_1149900171.1484052539792 Content-Type: multipart/alternative; boundary="----=_Part_2524_1908813640.1484052539793" ------=_Part_2524_1908813640.1484052539793 Content-Type: text/plain; charset=UTF-8 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 casts int value to a > target enum type if int value represents a valid enumerator. > > template > optional enum_cast(Int value); > > requires: is_enum, is_integral > > enum color > { > red = 1, > green = 200, > blue = 3 > }; > > static_assert(enum_cast(200u) == color::green); > static_assert(enum_cast(3) == color::blue); > static_assert(enum_cast(4) == 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, but > 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 > __builtin_* intrinsic). > > Regards, > Maciej > I was thinking some more about this proposal. I really think the functionality you suggest is a good idea. I hope you proceed with a proposal. If you decide not to let me know. 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. } // 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); } 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 ) noexcept { 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 routines to get good error // messages / report how they wish when they wish: // Some type that holds the largest enum value ever possible. using std::any_enum_value = unspecified; class bad_enum { public: std::any_any_enum_value bad_enum_value; std::string enum_type_name; }; 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 more. and saves the user writing redudant boiler plate code that the compiler 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 exceptions. * We don't depend on optional. * 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 bad_optional_access. * make_bad_enum means we can create an error class for reporting elsewhere - we don't have to throw it. * make_bad_enum means we don't expose any get enum_type_name function the reflection people will reproduce. * make_bad_enum gives people flexibility to throw when they are ready instead of forcing a throw as soon as conversion fails. * Might play well with structured bindings. Main choices: * We could model this on optional i.e. include has_value etc. but it seems simpler not to. Either way is fine to me. I'm not sure such safety is warranted and from_chars/to_chars is pretty simple too so I went that way. * The caller has all the utilities here to build that or work 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 or is used. i.e. include the enum type name and bad value in the error. * I've used std::range_error as the exception type for failure but another may be appropriate. bad_enum as an exception type contains the value that was bad and the type name that it failed to convert to. This would allow people to extract the values to construct their own error messages (perhaps in other languages like French etc.). If std::bad_enum is too much API, that could be dropped for just 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 ideas and views. Hope this helps. Thanks GM -- 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 email 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/57258435-5d82-48e7-8ed7-3c38682418fb%40isocpp.org. ------=_Part_2524_1908813640.1484052539793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, January 3, 2017 at 10:56:05 PM UTC+13,= m.ce...@gmail.com wrote:
Hi,<= div>
I propose to add a enum_cast function that safely casts = int value to a target enum type if int value represents a valid enumerator.=

template<= span style=3D"color: rgb(0, 0, 0);"> <typename= Enum, typename Int>
optional<= span style=3D"color: rgb(102, 102, 0);"><Enum> enum_cast(I= nt value);
=
requires: is_enum<Enum>= , is_integral<Int>

enum color
= {
=C2=A0 =C2=A0red =3D 1= ,
=C2=A0 =C2=A0green = =3D 200,
=C2=A0 =C2=A0blue =3D 3
};

stat= ic_assert(enum_cast<color>(<= /span>200u= ) = =3D=3D color::green);
static_assert(enum_cast<color>(3) color::);
static_assert(enum_cast<color>(4) =3D=3D nullopt);

=

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

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

I know this could be p= urely library extension if based on reflection, but since we don't know= when we will get reflection,
and implementation based on reflect= ion may not be optimal,
I think it should be implemented with com= piler support (i.e. via __builtin_* intrinsic).

Re= gards,
Maciej


I was thinking some more about this proposal. I really think the fu= nctionality you suggest=C2=A0is a good idea.
I hope you proceed w= ith a proposal.=C2=A0If you decide not to let me know.

=
I hope this post assists you with your proposal.=C2=A0My suggestions a= re for your proposal to look something like this:

= In <utility> I think add:

bool template<t= ypename E, typename V> is_enum( V ev )
{
=C2=A0// co= mpiler=C2=A0magic:
=C2=A0// Calling this routine causes the compi= ler 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. ot= herwise false.
}

// Users call this rout= ine to convert an integer to an enum.
They call this if they=C2= =A0aren't sure about=C2=A0their conversion data
// and don= 9;t mind exceptions and want simple like std::to_string
// They m= ight expect such a function to be present.
// Though to be fair I= 'm not sure we should encourage this?
//=C2=A0They should get= good error messages.
template<typename E, typename V> E to= _enum_or_throw(V ev)
{
=C2=A0if (is_enum<E>(ev))<= /div>
=C2=A0=C2=A0return static_cast<E>(ev);
=C2=A0thro= w make_bad_enum<E,V>(ev);=C2=A0
}

=
template<typename E> class to_enum_result
{
= public:
=C2=A0E enum_value;
=C2=A0bool is_valid;
<= div>};

// Call this if you can't use/aff= ord exceptions. It seems optimal?
template<typename E, typenam= e V> to_enum_result<E> to_enum( V ev ) noexcept
{
<= div>=C2=A0 if (is_enum<E, V>(ev))
=C2=A0=C2=A0=C2=A0 return= to_enum_result<E>{true,static_cast<E>(ev)};
=C2=A0 r= eturn to_enum_result<E>{false, E{}};
}

=
// if is_valid=C2=A0returns false after to_enum, the user can use thes= e routines to get good error
// messages / report how they wish w= hen they wish:

// Some type that holds t= he largest enum value ever possible.
using std::any_enum_val= ue =3D unspecified;

class bad_enum
{
public:
=C2=A0=C2=A0=C2=A0std::any_any_enum_va= lue bad_enum_value;
=C2=A0=C2=A0 std::string enum_type_name;
}= ;
=C2=A0
template<typename E, typename V> std::bad_enu= m make_bad_enum(V ev)
{
=C2=A0// Use some compiler magi= c 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}'= is not a legal value for an enum of type '{E}'
=C2=A0ret= urn std::range_error(msg);
}


<= div>
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 valid= ity and no more.
and saves the user writing redudant boiler plate= code that the compiler does better.
* to_enum_or_throw() is ther= e for people who find simple works for them.
its name makes it cl= ear that exceptions can happen.
* to_enum() is there for people w= ho need performance and without exceptions.
* We don't depend= on optional.
* Means <utility> isn't dependent on opti= onal if we put it there.
* make_bad_enum avoids making bad_e= num a template.
* make_bad_enum gives us good error messages and bette= r than bad_optional_access.
*=C2=A0make_bad_enum means=C2=A0we ca= n=C2=A0create an=C2=A0error class=C2=A0for reporting elsewhere -=C2=A0we do= n't have to throw it.
*=C2=A0make_bad_enum means we don't= expose any get enum_type_name function the reflection people will reproduc= e.
* make_bad_enum gives people flexibility to throw when they ar= e ready instead of forcing a throw as soon as conversion fails.
*= Might play well with structured bindings.

Main ch= oices:
*=C2=A0We could=C2=A0model this on optional=C2=A0i.e. incl= ude=C2=A0has_value etc.=C2=A0but it=C2=A0seems simpler not to. Either way i= s fine to me.
I'm not sure such safety is warranted and=C2=A0= from_chars/to_chars is pretty simple too so I went that way.
* 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 important.
This tries to=C2=A0enable making decent errors available no matter wh= at method or=C2=A0is used.
=C2=A0i.e. include the enum type name = and bad value in the error.
* I've=C2=A0used std::range= _error as the exception type=C2=A0for failure but another may be appropriat= e.
bad_enum as an exception=C2=A0type=C2=A0contains the value tha= t was bad and the type name that it failed to convert to.
This=C2= =A0would allow people to extract the values to construct their own error me= ssages (perhaps in other languages like French etc.).

<= div>If std::bad_enum is too much API, that could be dropped for just std::r= ange_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=C2=A0Committee's disposition towards=C2=A0the= se ideas and views. Hope this helps.

Thanks
<= div>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/57258435-5d82-48e7-8ed7-3c38682418fb= %40isocpp.org.
------=_Part_2524_1908813640.1484052539793-- ------=_Part_2523_1149900171.1484052539792-- .