220 30204 <1d5db671-8ee9-49dc-937d-10a20f48fe73@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, 3 Jan 2017 15:48:25 -0800 (PST) Lines: 192 Approved: news@gmane.org Message-ID: <1d5db671-8ee9-49dc-937d-10a20f48fe73@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_7355_748560630.1483487305094" X-Trace: blaine.gmane.org 1483487315 6041 195.159.176.226 (3 Jan 2017 23:48:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2017 23:48:35 +0000 (UTC) Cc: m.cencora@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBSPQWDBQKGQEOCSU6QQ@isocpp.org Wed Jan 04 00:48:26 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOYoY-0008Sa-Pa for gclcip-std-proposals@m.gmane.org; Wed, 04 Jan 2017 00:48:23 +0100 Original-Received: by mail-io0-f199.google.com with SMTP id m204sf14207502ioe.6 for ; Tue, 03 Jan 2017 15:48:26 -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=Wr9lcFnGc33KhOoQiXcJAk4/gyy5UiQSsVN4bofFIf4=; b=jDs6A41K8I9wKrqO4Lo6bfkl13KKgklijGZ1FLxQP3yt8d1IgEjuLt1zavbayuPG2X HRhjMDz4b3y6qoC1Uu7YfJd6Wp39nEoEFLgHJLjP3WM3xXoKyqxDte3m1AzK3/me1VTM i/jvZNk53TWjJryYs3Cqe7xsl8sQW4bCcaXuqMkSNkO9RHc0Q8FgLwkuSBO9TPYkaQg9 u7zLbXGbWrbYE852yDGeaCJfv0vEaFfn78wnilRGa5K5D+csXfC629pUE/x6CXQhtSru G7KtoKdKkWH0vqd/R3e/yA6F0eMx+FSL5RvehQIdW0HbS+JfO7RmiLWpNdnmU67CuUhk KyHQ== 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=Wr9lcFnGc33KhOoQiXcJAk4/gyy5UiQSsVN4bofFIf4=; b=M8lRakHsqojSN4zPkkBc4ehjGxpjxaUbm5Iuv19ufpF8eiqBe7VnMOCUQD2d0OYbC9 w+ScGTddb2/R0UpAi2bNJyHYEBr85QqV347xYhZvtrRjVpF0r8Pql4cBiqCXo+c7HbB2 EVzxu1K5CirGItU1qZ9+vKiFEV4Ye8unabvMfoOIqLvQAujUAJxsMnd/BSaULlQ5p2yM 74W7d18/VoF9wdLDgRFYajCU6L9S3YQfec2I5y/80Vf1U3I40Oq2lYtb+OEe+YRtwttn 7zaQMhvsse272/Gf3pmEd7+Ut2NQSh+igD2HQT2diDiPYuIKtGLEmoTxRyinNhGxDKmL TxMw== 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=Wr9lcFnGc33KhOoQiXcJAk4/gyy5UiQSsVN4bofFIf4=; b=LXXtBKT7+1hNrxELoVnURfNfQvuEFLU0xxjNG0DJDt8geQwFEC3oChtlktT+lFMYYH wYGzhbHR6jr+4SoAg6mO1jqfWYlmO+DwZWShi7gBPvQhEb5Jpljle5a+QRNpn5msuTc/ i80lmtgQvJZ1Tftg+jkRE8SLUNyIg8SRrACHqwDVDi2cWOnXDgkaqpTJ3733/Q5/+hLp G/7F6R1UdKbXK/HJbP1mMKii9LRRpd24ln1oL9qAV39MSnkKTPXCeflwhxQ1URQxBf5n C2gy75hULadgC/C1/tPZ4GR0v000XmwF2kfco8twE0JwYYsHwGCoLEPrMG1mrPH5cVSJ D1Lw== X-Gm-Message-State: AIkVDXKXeZWN+7VT+3I415oS6GPTUZSvkZnEVRejL44Jy6XlxFcG5VC4mx/HDT2+CEhnPw== X-Received: by 10.107.24.70 with SMTP id 67mr15346861ioy.99.1483487306323; Tue, 03 Jan 2017 15:48:26 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.32.170 with SMTP id x39ls41760362ota.23.gmail; Tue, 03 Jan 2017 15:48:25 -0800 (PST) X-Received: by 10.157.35.89 with SMTP id k25mr2186886otd.11.1483487305669; Tue, 03 Jan 2017 15:48:25 -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:30204 Archived-At: ------=_Part_7355_748560630.1483487305094 Content-Type: multipart/alternative; boundary="----=_Part_7356_407506877.1483487305094" ------=_Part_7356_407506877.1483487305094 Content-Type: text/plain; charset=UTF-8 Just considering my earlier make_enum comment further, The ultimate minimum for C++ is surely this?: traffic_light light{}; // whatever default. bool guaranteed_success = std::can_cast_enum(x); if (guaranteed_success) light = reinterpret_cast(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 seems more C++ like, but forgets C, which probably people feel is not a concern anyway. But other wise some special C and C++ syntax like can_cast_enum(traffic_light, x) would seem to cover both languages if that's desirable. 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 > -- 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/1d5db671-8ee9-49dc-937d-10a20f48fe73%40isocpp.org. ------=_Part_7356_407506877.1483487305094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just considering my earlier make_enum = comment further, The ultimate minimum for C++ is surely this?:
traffic_light light{}; // whatever default.
bool guaranteed= _success =3D std::can_cast_enum<traffic_light>(x);
if (guar= anteed_success)
=C2=A0light =3D reinterpret_cast<traffic_light>(x)= ;
// else error condition.

It separates = the validity check from the conversion and then you can build whatever on t= hat, i.e. assign, atomic assign, etc.
This seems more C++ like, b= ut forgets C, which probably people feel is not a concern 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 languages if that'= ;s desirable.


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 vali= d enumerator.

tem= plate <ty= pename Enum, typename Int>
opt= ional<Enum> enum_cast(Int value);

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

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

static_assert= (enum_cast<color>(200u)<= /span> =3D=3D color::green);static_assert(enum_cast<color>(3) =3D=3D color::blue);
static_assert= (enum_cast<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 do we want this:<= br>
=C2=A0- validation of input data (e.g. coming from user or de= serialization).
=C2=A0- other?

I know th= is could be purely library extension if based on reflection, but since we d= on't know when we will get reflection,
and implementation bas= ed on reflection may not be optimal,
I think it should be impleme= nted with compiler support (i.e. via __builtin_* 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/1d5db671-8ee9-49dc-937d-10a20f48fe73= %40isocpp.org.
------=_Part_7356_407506877.1483487305094-- ------=_Part_7355_748560630.1483487305094-- .