220 29252 article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: explicit conversion from enum class to its underlying type Date: Sun, 30 Oct 2016 08:50:16 +0100 Lines: 302 Approved: news@gmane.org Message-ID: References: <4afed494-4fc5-4b06-b3e7-255aa293068e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------088B6F84F87115FA27FCC891" X-Trace: blaine.gmane.org 1477813834 24368 195.159.176.226 (30 Oct 2016 07:50:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Oct 2016 07:50:34 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBOOM23AAKGQEUHXBL3I@isocpp.org Sun Oct 30 08:50:29 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c0ksh-0003vc-HJ for gclcip-std-proposals@m.gmane.org; Sun, 30 Oct 2016 08:50:15 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id m193sf25855122lfm.7 for ; Sun, 30 Oct 2016 00:50:18 -0700 (PDT) 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=bM98ZtK51Nk/U8AbPrxZrVUXw3W9PKzI9U7fJ0PmfNY=; b=MM5SmIzfAyiBjl3i2vg8C4lKBdiSAbl3zI1JlEYXTCmCZQvpNCYY9dyGIPj2SuMvMZ nWDNoPPcCifK5fzWjy/R1BuePVb/71k3bTn7iGfSyDtKmLLxoU+YbHQg9w/UCIpvgEvs 2XeJkWO+X3fUU+zMLf3EHUZPgG1M1c0t+9u8M3ma2zL+uy9+e2w/P7KxLg+Hi2qxxv5+ 67KZiI3G80grouoId56A4z7B5sEMIbLlAHEpIqwsUINwykoe7i6yjRXKQI6gi2vl/AB6 HuX1JCeR9tfwZYAhxL9VyIcgO96HXVB9ZjW8Tfv2cSAbeOibHCPj8xtJuA+/gDiEJkWV D65A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=bM98ZtK51Nk/U8AbPrxZrVUXw3W9PKzI9U7fJ0PmfNY=; b=G6k4ZKqZ1wTIQ6q6W1jC13+tIJnLPItEebHMZy2phMSrcKONv5YNFyB/i2Us8QjR4f 7MhfgM4T3OAUGinJA2GlWQ7RbhdNvJPhxPuWnjgWsC/63NMUQdWcywbAYaPdmQP3Yc3a gZLbxGwVT5G2naS3Wa0xPMLBXM00qJ6J5hYUNxiNpxYHDxBsKJ1bufxT/+TXWlBregrV xeugiJSGfzijwMpWBQlv+iwLHZvNFI5RE6ywJMNEPb6g6/7xH3UFwCkP5Ikn5fqVbqJ9 XuZwg6mEfHEH9gOllxgwkECkd5OPbxMSRD/9f9pDoZILnL4/h9MLmr9vTCSnWdOdyKuZ HGfA== X-Gm-Message-State: ABUngve5N3MnwZ2sIGs0GwCX4zi4K7jVqVpvkVNftbfZ7VxNLkMtS+OcVChw3d2G+3dRBg== X-Received: by 10.25.199.149 with SMTP id x143mr1697774lff.21.1477813818529; Sun, 30 Oct 2016 00:50:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.193.130 with SMTP id r124ls184869wmf.6.canary-gmail; Sun, 30 Oct 2016 00:50:17 -0700 (PDT) X-Received: by 10.194.87.170 with SMTP id az10mr20688436wjb.189.1477813817286; Sun, 30 Oct 2016 00:50:17 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr. [80.12.242.127]) by mx.google.com with ESMTPS id n62si18518319wme.113.2016.10.30.00.50.17 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 30 Oct 2016 00:50:17 -0700 (PDT) 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 pc29.home ([2.13.11.7]) by mwinf5d40 with ME id 1jqF1u00C0973YJ03jqGlb; Sun, 30 Oct 2016 08:50:17 +0100 X-ME-Helo: pc29.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sun, 30 Oct 2016 08:50:17 +0100 X-ME-IP: 2.13.11.7 In-Reply-To: <4afed494-4fc5-4b06-b3e7-255aa293068e@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:29252 Archived-At: This is a multi-part message in MIME format. --------------088B6F84F87115FA27FCC891 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 29/10/2016 =C3=A0 23:51, Andrzej Krzemie=C5=84ski a =C3=A9crit : > Hi All, > > One of the nice safety features of enum classes is that they cannot be=20 > implicitly converted to their underlying type. However, do you think=20 > we would lose this safety feature if we allowed an explicit conversion=20 > to the underlying type? > > I do not know of any practical use of explicit conversion operators=20 > except for the contextual conversion to bool. And it is only this=20 > conversion that I am interested in. This works already in a non-contextual conversion, isn't it? bool(e) I believe the missing contextual conversion merits an issue. BTW, Boost.ScopedEnum emulation defined an explicit conversion on=20 compilers with them and without enum class. > > It would be beneficial to have a unique Boolean type that would not be=20 > convertible to another unique Boolean type. One solution is to use an=20 > enum class with `bool` as underlying type: > > | > enumclassSkipUnused:bool{No,Yes}; > enumclassSkipNeative:bool{No,Yes}; > > voidprocess(SkipUnusedskipUnused) > { > if(skipUnused)// doesn't compile > {} > } > | > > Unfortunately, such enum-based type does not work with boolean=20 > expressions. It would we had an explicit conversion. Well, this is a common problem due to the fact we are missing=20 strongly(opaque) types. | | > > Do you think, it would be acceptable to add such explicit conversion=20 > to the underlying type, for enum classes? Given that the explicit cast to the underlying type works already, I=20 believe it is a reasonable feature, and I don't know what could be the=20 reason to don't define it. Maybe some know it. SkipUnused e{}; if (bool(e)) std::cout << "Yes\n"; else std::cout << "No\n"; When we want to be explicit without naming the type I would add a=20 function, but this is not your case. template auto underlying(E e) { return static_cast>(e); } auto x =3D underlying(e); 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/f380095f-96be-d02f-584b-6821f70a20b2%40wanadoo.f= r. --------------088B6F84F87115FA27FCC891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 29/10/2016 =C3=A0 23:51, Andrzej Krzemie=C5=84ski a =C3=A9crit=C2=A0:
Hi All,

One of the nice safety features of enum classes is that they cannot be implicitly converted to their underlying type. However, do you think we would lose this safety feature if we allowed an explicit conversion to the underlying type?

I do not know of any practical use of explicit conversion operators except for the contextual conversion to bool. And it is only this conversion that I am interested in.

This works already in a non-contextual conversion, isn't it?

=C2=A0=C2=A0=C2=A0 bool(e)

I believe the missing contextual conversion merits an issue.

BTW, Boost.ScopedEnum emulation defined an explicit conversion on compilers with them and without enum class.

It would be beneficial to have a unique Boolean type that would not be convertible to another unique Boolean type. One solution is to use an enum class with `bool` as underlying type:

enum class SkipUnu= sed : bool { No, Yes };
enum class SkipNea= tive : bool { No, Yes };

void proces= s(SkipUnu= sed skipUnused)
{
=C2=A0 if (skipUnu= sed) // doesn't compile
=C2=A0 =C2=A0 {}
}

Unfortunately, such enum-based type does not work with boolean expressions. It would we had an explicit conversion.
Well, this is a common problem due to the fact we are missing strongly(opaque) types.

Do you think, it would be acceptable to add such explicit conversion to the underlying type, for enum classes?
Given that the explicit cast to the underlying type works already, I believe it is a reasonable feature, and I don't know what could be the reason to don't define it. Maybe some know it.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SkipUnused e{};
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (bool(e))
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std:= :cout << "Yes\n";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 std:= :cout << "No\n";

When we want to be explicit without naming the type I would add a function, but this is not your case.

template <typename E>
auto underlying(E e)=C2=A0 { return static_cast<underlying_type_t<E>>(e); }

auto x =3D underlying(e);

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/f380095f-96be-d02f-584b-6821f70a20b2= %40wanadoo.fr.
--------------088B6F84F87115FA27FCC891-- .