220 30200 <53189e5e-b1cf-0411-c87e-542822dbd4c0@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: enum_cast proposal Date: Tue, 3 Jan 2017 23:04:07 +0100 Lines: 273 Approved: news@gmane.org Message-ID: <53189e5e-b1cf-0411-c87e-542822dbd4c0@wanadoo.fr> References: <119a6ed9-e6b1-4c8c-b9b1-5152f7c7a3d6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C1C7E62816EDEEF8C649CDE1" X-Trace: blaine.gmane.org 1483481070 26433 195.159.176.226 (3 Jan 2017 22:04:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2017 22:04:30 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBZN7WDBQKGQEJRKRRJY@isocpp.org Tue Jan 03 23:04:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cOXBp-0005hL-E5 for gclcip-std-proposals@m.gmane.org; Tue, 03 Jan 2017 23:04:17 +0100 Original-Received: by mail-lf0-f72.google.com with SMTP id l68sf184593757lfb.1 for ; Tue, 03 Jan 2017 14:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references: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=B5lEcisEpGKeMXhCRgJfE9g88jWij0cTztOfNJ0K5ik=; b=iTgUMYNQw63PMhHhs0cQyaNca9gwfU6h4dgjj7kbqW5aWdjdMCk+A/qn0xkWw5OOwd QFjPemsogCUF7gLL0kr6CXVu168CeVzNUlZm1H94Kck5B+jo40pgZpR8NxJlwR1VHqwt VA/luscUEHXITdSvHrakaMRBwqxUtApBGepaNbtYgUsATYpc7KP7T1RM5I9IEj4jZPc+ Y8Ms9ur5GpMT/ASsRww1VSYYvJp7OoLZUfSo4ValSd+n0yQcUCM30t0ysxBJqnP48nc1 4dbylgV3cCJ6xhpqCgLcw2cslG8xG5gAeZizHgK4ps3ZjQMnaPLqQBXgDw3sEeBl2Rn6 1vpg== 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: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=B5lEcisEpGKeMXhCRgJfE9g88jWij0cTztOfNJ0K5ik=; b=QhMC3QiwTxetfWdzY4wAh38VpgzZLNSI4or5nUkdwXhJfcCcn4f+zIRGLqbNsesj1o qyVXSNiQSnBcVAFYz0I0HBOSraMUkADjMUlr/0JIKss9lhwHh2fCXiM6EUHGTnr4bxHg Z0BNg7JLfqx26mXYa4b4T/eiWwoBmfaMrtdmEJMggY0Jnhk9lJlOf0rpe5WIFRSV8D2F aWse3LN+Us3d/BMmhlIWN9EUVZCZuQ3Gtr/YSrTtdgGsaeywrrat2qxHiOnX3je/gf6t WEIm+p5UQzZu33vIWWj8lP3JqhXY9BMOCmi3zQEmxGxkGKXNqkct+g6iz8C6jycugis8 OPmQ== X-Gm-Message-State: AIkVDXJ0ATgBYN9R0WS7VWXldLSAjsd4Odt8S/UtJ8RXK90kVi85YknvNk8mL4JCUGdArQ== X-Received: by 10.46.21.65 with SMTP id 1mr6002018ljv.4.1483481061785; Tue, 03 Jan 2017 14:04:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.168.202 with SMTP id r193ls5826137wme.17.canary-gmail; Tue, 03 Jan 2017 14:04:20 -0800 (PST) X-Received: by 10.194.221.4 with SMTP id qa4mr65353974wjc.179.1483481060705; Tue, 03 Jan 2017 14:04:20 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr. [80.12.242.127]) by mx.google.com with ESMTPS id b188si75123359wme.154.2017.01.03.14.04.20 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 03 Jan 2017 14:04:20 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.127 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.127; Original-Received: from imac-de-vicente-botet-escriba.home ([92.139.156.24]) by mwinf5d62 with ME id Ty471u00F0Xrduc03y47ia; Tue, 03 Jan 2017 23:04:20 +0100 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Tue, 03 Jan 2017 23:04:20 +0100 X-ME-IP: 92.139.156.24 In-Reply-To: <119a6ed9-e6b1-4c8c-b9b1-5152f7c7a3d6@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.127 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:30200 Archived-At: This is a multi-part message in MIME format. --------------C1C7E62816EDEEF8C649CDE1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 03/01/2017 =C3=A0 19:43, Nicol Bolas a =C3=A9crit : > > > On Tuesday, January 3, 2017 at 1:25:20 PM UTC-5, Vicente J. Botet=20 > Escriba wrote: > > Le 03/01/2017 =C3=A0 10:56, m.ce...@gmail.com a =C3=A9c= rit : >> 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 >> optionalenum_cast(Intvalue); >> >> requires:is_enum,is_integral >> >> | >> >> 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). >> > Hi, I believe this could be useful. Library implementers could be > free to use builtins or reflection once it is there. > > Now, I believe that we need two kind of functions. One that is a > cast and that says just that we are casting. It would be the same > as a static_cast. Something like gsl::narrow_cast so that we > express better the intent. In addition we need the function you > are proposing similar to gsl::narrow. > The question is how the function reports errors. If we use > exceptions, I agree with Nicol that a specific exception would be > better. > > I will then propose > * enum_cast ~static_cast > > > What's the point of `enum_cast`, save the fact that it would SFINAE on=20 > the given type being an actual enumeration? `static_cast` is the=20 > standard way of saying "make this integer an enum without checking". I=20 > don't think we need another way to spell that. What is the point of narrow_cast? I believe it is useful to know the=20 kind of cast we are using. This helps to inspect the code we (others)=20 have written in a more efficient way. > > * to_enum : throw exception if error > * try_to_enum : returns optional or an interface based on > error_code (like from_chars). status_value and expected can be > considered also once adopted. > Do we expect several error conditions? > > > Well, there's only one failure state: the given value is not in the=20 > enumeration. As such, I see no need for using complicated objects that=20 > store errors; `optional` should be sufficient. If there is only one error case, yes optional is a good candidate. However it would be weird to have a different exception depending on=20 whether the user uses to_enum or try_to_enum (or whatever names are more=20 appropriated) 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/53189e5e-b1cf-0411-c87e-542822dbd4c0%40wanadoo.f= r. --------------C1C7E62816EDEEF8C649CDE1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 03/01/2017 =C3=A0 19:43, Nicol Bolas = a =C3=A9crit=C2=A0:


On Tuesday, January 3, 2017 at 1:25:20 PM UTC-5, Vicente J. Botet Escriba wrote:
Le 03/01/2017 =C3=A0 10:56, m.ce...@= gmail.com a =C3=A9crit=C2=A0:
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 <typename Enum, typename Int>
optional<Enum> enum_cast(Int value);

requires:<= span style=3D"color:#000"> is_enum<Enum>, is_integral<Int>


Why do we want this:
=C2=A0- validation of input data (e.g. coming from use= r 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 implementation based on reflection may not be optimal,
I think it should be implemented with compiler support (i.e. via __builtin_* intrinsic).

Hi, I believe this could be useful. Library implementers could be free to use builtins or reflection once it is there.

Now, I believe that we need two kind of functions. One that is a cast and that says just that we are casting. It would be the same as a static_cast. Something like gsl::narrow_cast so that we express better the intent. In addition we need the function you are proposing similar to gsl::narrow.
The question is how the function reports errors. If we use exceptions, I agree with Nicol that a specific exception would be better.

I will then propose
* enum_cast ~static_cast

What's the point of `enum_cast`, save the fact that it would SFINAE on the given type being an actual enumeration? `static_cast` is the standard way of saying "make this integer an enum without checking". I don't think we need another way to spell that.
What is the point of narrow_cast? I believe it is useful to know the kind of cast we are using. This helps to inspect the code we (others) have written in a more efficient way.
=C2=A0
* to_enum : throw exception if error
* try_to_enum : returns optional<Enum> or an interface based on error_code (like from_chars). status_value and expected can be considered also once adopted.
Do we expect several error conditions?

Well, there's only one failure state: the given value is not in the enumeration. As such, I see no need for using complicated objects that store errors; `optional` should be sufficient.
If there is only one error case, yes optional is a good candidate.
However it would be weird to have a different exception depending on whether the user uses to_enum or try_to_enum (or whatever names are more appropriated)


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/53189e5e-b1cf-0411-c87e-542822dbd4c0= %40wanadoo.fr.
--------------C1C7E62816EDEEF8C649CDE1-- .