220 30219 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: Wed, 4 Jan 2017 00:47:22 -0800 (PST) Lines: 214 Approved: news@gmane.org Message-ID: References: <1d5db671-8ee9-49dc-937d-10a20f48fe73@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2430_1124105057.1483519643033" X-Trace: blaine.gmane.org 1483519651 27624 195.159.176.226 (4 Jan 2017 08:47:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jan 2017 08:47:31 +0000 (UTC) Cc: m.cencora@gmail.com, gmisocpp@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD7YFUMJRYMBBG7NWLBQKGQES3XW7LI@isocpp.org Wed Jan 04 09:47:27 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOhE8-00066D-3u for gclcip-std-proposals@m.gmane.org; Wed, 04 Jan 2017 09:47:20 +0100 Original-Received: by mail-it0-f72.google.com with SMTP id k132sf13121576ita.7 for ; Wed, 04 Jan 2017 00:47:24 -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=D/cAyGscVPNpUU1KsznVvVBQqHxqiesOtHgtlX9t9o4=; b=ewc08bIZLBhQ8VpYjWLA+5EBwcdFK9kS/q1yZZGQNjFkQVlU1VTvBqyh+3FGWDsizN GA35oQCz3SKiYo4jxL2ePOBs9rgpeCHBYzRHJ3q0ddRXB5AAS5z3Nj80oZGqimAEiA++ t/KVQy+ObcbXXxc6YLL4ICP7Q8ePvBi9bVuJDGi1vhF+GJIyWfMaoQl1+3PpRcvyfU0P /M9Umc6ZqqSu6RgfmpZLrrKUe88zLtUS9KS4VOV/Pw/6OzhUQ7m245BXSeHtL6v7mQ2N KhFC9p/MrfCLFUf4yWHSE2tPqV+UtaOJ/tLQB7LT36WjduDojO30uJ51or/SSa1geT7x plnQ== 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=D/cAyGscVPNpUU1KsznVvVBQqHxqiesOtHgtlX9t9o4=; b=AaQaoS+v2rvQRud684rRxWvyByqt0REjAk0u96iqt4kk3CqQPoph8th2YhPJy6MB8l 3zbokt5im11u/qLjM5VQcWzbhKErJttX0BCQJOAGsXUgp797S2VXjvUUCc8WPQYwt7D5 0TD5hvRoKCuXeyPHuf7M/6eWTBC00Hk5G8RhO7PrkD8dxEZYlu0O6vfXV5x6+Eq0o5nU JdnzR5Ob54v5gUOcT8WSC9vOy27oCK45UGP7oeO3Kc2L/04QhLmTzkupWdcQfsxp5nRA tr30kYG+CWTWtralgIeCdH1iwPKMR0fA5CanjLC+2W2oPKTLSyz7LijnbSDBrWgfLaKt X/PA== 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=D/cAyGscVPNpUU1KsznVvVBQqHxqiesOtHgtlX9t9o4=; b=g6to0AytxH+LToDA02VXwsj8nveRUHapJWcvWCJI8dmIxvxSFq/zb52lXCa6/omGuK xfg8CF4KNvmtGZQyhOb1S9z1siTMw8a1Gpm+eHTNp0u8ihdnYymkFnmeDlY9a7nWJ587 aiBXPkQ4lagyR4I2EGrp0+gneoC7pbtvS0yrovHCIXuVhoT50Bx56f73TWLmn0bf50DO Jlcbi3giN8P6wn4MWbMPQ35YGQBTiTftb1GhyMH7CW2rwKGaozixY8oPHIYgcBaRU7Xq 6RhMH4imsLlJRg1b441Umc5rs3cfgxncJ2lhL0JHQwl6rFWO067msqVr+lSWmY5hiuCT T+wA== X-Gm-Message-State: AIkVDXKnRC6QWVsXfPSTCkerrPiG7EwshcU2qbUA7OUMlTAdCTMWUk41rVH1pLSg5mHFfg== X-Received: by 10.36.71.130 with SMTP id t124mr14370783itb.1.1483519644104; Wed, 04 Jan 2017 00:47:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.54.168 with SMTP id h37ls9015150otc.45.gmail; Wed, 04 Jan 2017 00:47:23 -0800 (PST) X-Received: by 10.157.17.167 with SMTP id v36mr3036238otf.12.1483519643424; Wed, 04 Jan 2017 00:47:23 -0800 (PST) In-Reply-To: <1d5db671-8ee9-49dc-937d-10a20f48fe73@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:30219 Archived-At: ------=_Part_2430_1124105057.1483519643033 Content-Type: multipart/alternative; boundary="----=_Part_2431_595074273.1483519643034" ------=_Part_2431_595074273.1483519643034 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu =C5=9Broda, 4 stycznia 2017 00:48:25 UTC+1 u=C5=BCytkownik gmis...@g= mail.com=20 napisa=C5=82: > > > Just considering my earlier make_enum comment further, The ultimate=20 > minimum for C++ is surely this?: > > traffic_light light{}; // whatever default. > bool guaranteed_success =3D std::can_cast_enum(x); > if (guaranteed_success) > light =3D reinterpret_cast(x); > // else error condition. > > It separates the validity check from the conversion and then you can buil= d=20 > whatever on that, i.e. assign, atomic assign, etc. > This seems more C++ like, but forgets C, which probably people feel is no= t=20 > a concern anyway. > But other wise some special C and C++ syntax like=20 > can_cast_enum(traffic_light, x) would seem to cover both languages if=20 > that's desirable. > > How would that can_cast_enum work in C without function overloading or=20 templates? =20 > > 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 >> > --=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/a38d1aa8-d461-4f70-81e7-abe36c36bb07%40isocpp.or= g. ------=_Part_2431_595074273.1483519643034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 4 stycznia 2017 00:48:25 UTC+1 u=C5=BCy= tkownik gmis...@gmail.com napisa=C5=82:

Just considering my earlier m= ake_enum comment further, The ultimate minimum for C++ is surely this?:

traffic_light light{}; // whatever default.
bool g= uaranteed_success =3D std::can_cast_enum<traffic_light>(x);
if (guaranteed_success)
=C2=A0light =3D reinterpret_cast<traffi= c_light>(x);
// else error condition.

It separates the validity check from the conversion and then you can = build whatever on that, i.e. assign, atomic assign, etc.
This see= ms more C++ like, but forgets C, which probably people feel is not a concer= n anyway.
But other wise=C2=A0some special C=C2=A0and C++ syntax = like =C2=A0can_cast_enum(traffic_light, x)=C2=A0would seem to cover both la= nguages if that's desirable.


How would that can_cast_enum work in C without function ov= erloading or templates?
=C2=A0

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 <= span style=3D"color:rgb(102,102,0)"><typename Enum,= typename Int&g= t;
optional<Enum= > enum_cast(= Int value);

requires: is_enum<Enum>, is_integral<Int>

enum color
{
=C2=A0 =C2=A0r= ed =3D 1,
= =C2=A0 =C2=A0green =3D 200,
=C2=A0 =C2=A0blue =3D 3
};<= br>
static_assert(enu= m_cast<color>(200u) =3D=3D color::<= span style=3D"color:rgb(0,0,0)">green);
static_assert(enum_cast<color>(3) =3D=3D color::blue)= ;
static_assert(enum_cast<color>(<= /span>4) =3D=3D nu= llopt);


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

<= /div>
Why do we want this:
=C2=A0- validation of input da= ta (e.g. coming from user or deserialization).
=C2=A0- other?

I know this could be purely library extension if base= d 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 __built= in_* intrinsic).

Regards,
Maciej

--
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/a38d1aa8-d461-4f70-81e7-abe36c36bb07= %40isocpp.org.
------=_Part_2431_595074273.1483519643034-- ------=_Part_2430_1124105057.1483519643033-- .