220 35413 article Path: news.gmane.org!.POSTED!not-for-mail From: j c Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allow out-of-class operator overloading for enum classes Date: Mon, 20 Nov 2017 17:16:54 +0000 Lines: 305 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045ef0dacf1b95055e6d4013" X-Trace: blaine.gmane.org 1511198219 15248 195.159.176.226 (20 Nov 2017 17:16:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2017 17:16:59 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCR6HLXQUAORBCE4ZTIAKGQEITW3N4Y@isocpp.org Mon Nov 20 18:16:55 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 1eGpgf-0003Lp-OG for gclcip-std-proposals@m.gmane.org; Mon, 20 Nov 2017 18:16:50 +0100 Original-Received: by mail-yb0-f199.google.com with SMTP id k40sf4145978ybj.21 for ; Mon, 20 Nov 2017 09:16:57 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1511198217; cv=pass; d=google.com; s=arc-20160816; b=KOcAVaw41V7+B7LC075BYs9/dVa1w5aRwRxCIl3bq3Gbp7opQPSh5CEJQEvL3TQcbS M7hz5FkTvlGl1Zvc7mHHibrxtWmgthrIUCFwUU/VR/1OkcMYnBhE6JUOiVpXa5VAnroh 1NuvDM6sSWvjuiDaVgMB/OgyCK1UU+jHcLYzljtB8j4B3zDNQJG/7mwTX/msEm9KXByf lDaX0jVYP6p1o/qpbca5OUN8fzfdEysIiWZN43KhFnf65xtkbcYHRee4lMQaWORci7ov Sn2SS6RC80t3hscduIJl4hDX49AAFmUyFwAnenBkFRqjkg8fgZj4cZGQIJ1bOLZe3MvN attQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=GMuB3pCTmlc8nWnj2Ra7xrgOCmlwn/5gO2yO/OqUxTs=; b=wCjy3ZoBB1SobeF4essbboIEgO/T6QWkJ1i06HMLwgJmveDXVLf9RPyXVH4CyYvEtv oSrEBDwVsCgBelNVnRgdrbsJICviSqeH1DAoCWHK7OX5XzzoaLMKjrXR/T92ibo1hl7Q Xvc6gxtM+todCE8JUXY1EFmhCxOwIO3EHMFZcMxha7Pqq7lm/vmW5I1J6/iWk2ygT+Dl +CMx3Zvwrhj1P9UnyMTSG+MrXV7UKre+Vu+lhQlwvpYC+lBpoGzW5v5Y8Cv376u3lWsc Kph1mmdj5eg8OiY0vuUKnDmTtxsuHADEqK8Q8MkZoaLwazaf/l4a++/qxm6Ec16dZvFr v5bQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eKOCMO6+; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=james.a.cooper@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=GMuB3pCTmlc8nWnj2Ra7xrgOCmlwn/5gO2yO/OqUxTs=; b=KYM4H9adRMPjNal+Z0vqj/VpNlcUT+QtMSydWyXiLkJdukGrBG4Jp0sw2SrycREtWE 9Ta6/dQYslhtwXs+ei/EL5I64PYGSAw3kkT7++oVLLQ0QuoRqFoED5j24DkbeMt4ofaD bLrgENlX3aOJLyb2NjeyOBF7u9G9g/WH2h0DjD/1QGV3bmXcl0upk6mbZJU+qFhE585t 1bhGdmXWZig4woknvI/mei9LjRMpNwVF8dNdQULeut3c2qvjcsU+KdJ0jsaqR4V4c3oq UwiZWNPFhjiYns/qVWnlT7V8SyX3880T1huX3GMqnrKvyci/GFK/bJuIAbQ9/uNNQdS8 TxZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=GMuB3pCTmlc8nWnj2Ra7xrgOCmlwn/5gO2yO/OqUxTs=; b=RAfWTndYEBFV389v/2LN+OCyPrAjgNXvisr/vFXWq/WSI6L260mr/4UkbxSqUqaNlk eNnQYeLTexrbzmKDvbKwdNC8WiR8MEkRzd6zi3aHbg0KO2ruKFeIgJtZPN8bxPz+5uV1 ebRQ/eNpzSq1gXHiLhRL6lgDNe7IlRXgbvsTEzj1wQL4VgJan40hsg6cSjeeLBwyehXV X/F03HeJVlOtiAYPYVTnXyAy4MxGZNSMtOQmhOWALPcKcSt8/JlSmWMeynlhX47ODC+7 JKMCl0O5eL5zsYkgQMNgoB8iPGYSer15e2R37u0iEHHhUInfCYZZyMNX/3cR59/DSRhu Ho9w== X-Gm-Message-State: AJaThX6HHHQ1MA7uavVJIFRY6Ggrt6H/5qdSkz6thiHbfECvD1eYzGMO oUlAx4EJi2YSBcSe1GK0GY+8fg== X-Google-Smtp-Source: AGs4zMYUfUh2f9G6vVZkX1SeHhZURpOjd9B2DthpdB61jRbZ94F43gkDI54q7RZ2udrMnk/M/iJhEg== X-Received: by 10.13.197.68 with SMTP id h65mr6679307ywd.169.1511198216945; Mon, 20 Nov 2017 09:16:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.13.236.15 with SMTP id v15ls618312ywe.38.gmail; Mon, 20 Nov 2017 09:16:55 -0800 (PST) X-Received: by 10.129.116.139 with SMTP id p133mr1208671ywc.74.1511198215828; Mon, 20 Nov 2017 09:16:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511198215; cv=none; d=google.com; s=arc-20160816; b=GGcCrcE5RyiBgwx32HGB4Gcbj7nZGiIApYO9E31MDARI2I/XqmzyNFNJzfWXwt9zND +pr7RffqV7GN47QGV/9j72bnN9RwdmrONZu1L9g7Wx3umWkrc9YoNyyWc+lp2Gnyxxf6 PKWUwM1Ydt2RNQ/x5jM1xSpWedHd9gQ8S+W6h28SQVMUkZJ28EOXVbRWA1/ou9goOYlb a0vOWOwhtqC2fyHaXiM4wBQKIqn8StoETP564nBnFchGh1ptWZXg2jNZ52MTpP2AUnB1 2GOF+xxDZe6KZUmkUpW180xqjzEQsf2JiuOCMjPfzRsIx9sErxQlk6vaQ8b4UXgm0gAF A96A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=u5wM3/rL0r51SHwZby797iPMYZkT6nP4JKrVfjWzskI=; b=JVYEqjAD83Ir453+GRlAk1YJUSGSUcUUQuFw6fIOw/zNOS6TohnmuNNqXyg8Ao1JBp w9j1s+2KJvkiHp2H7XmvdIQunUnM/9aeMcCwyGM1BX82j7NVSXj+UwmuC2rMg3Mwm2tZ H2fJ5YwxixkunGpAvUOuu0tyVhqBm4tsDyd4cP7kL/VzcVEbNuu1IHJ8ljBgQmhwAXPj UNQFWvbB6G9HEi21pUlnml7xpMY2mngk79kCLfIz+mBim2nqreOruwWxVCAc/kg98KTz /OEOoM8cHg6zZuygVsKNISSbhjvHrVjHvY+S8HpAUB+pbRRSVBnSTDSDlgEakTNQ+pIO V/AA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eKOCMO6+; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=james.a.cooper@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id d205sor3547316ywc.547.2017.11.20.09.16.55 for (Google Transport Security); Mon, 20 Nov 2017 09:16:55 -0800 (PST) Received-SPF: pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.129.118.17 with SMTP id r17mr9563633ywc.497.1511198215312; Mon, 20 Nov 2017 09:16:55 -0800 (PST) Original-Received: by 10.37.183.200 with HTTP; Mon, 20 Nov 2017 09:16:54 -0800 (PST) In-Reply-To: X-Original-Sender: james.a.cooper@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eKOCMO6+; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=james.a.cooper@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:35413 Archived-At: --f403045ef0dacf1b95055e6d4013 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I posted here previously about adding a 'std::underlying_cast' for enums. People agreed with the concept, but not the name (which is fine). On Mon, Nov 20, 2017 at 4:59 PM, Aar=C3=B3n Bueno Villares wrote: > Enum classes doesn't allow, by default, implicit conversion, not even to > the underlying type: > > enum class A : int { zero, one }; > void foo(int) {} > > int main() { foo(A::zero); } > > and that is a good thing, but sometimes, you need a enum class only to > avoid name colissions, for example: > > enum class table1_cols { id, name }; > enum class table2_cols { id, address }; > > If table1_cols and table2_cols were raw enums, there would be a colission > between both id named values, since they have global namespace scope, but > your intention is to treat them as raw enums to pass to other functions > receiving integers, comparing them, using them on switchs, and so on, but > still be forced to qualify its use with enum_type::value syntax for > security reasons. > > You can of course create a parametrized class for enums with the suitable > overloads of comparision operators and conversions operators and > constructors, but then you have an extra layer of qualification when > dealing with those values (for example, > *enum_wrapper(table1_cols::id)*, or just > *enum_wrapper(table1_cols::id)* in C++17, but I think that is an > innecesary extra typing anyway. > > I know that is not hard to just cast it using the C-notation, like *(int)= table1_cols::id, > *but in certain situations you have a mix of int, unsigneds, and enums, > for example, because you use enums as indexes for your own purposes (and > thus you deal with std::size_t's) and interact with third party libraries > that uses ints (for example, model indexes), or make temporary arithmetic > operations with unsigneds that forces you to cast them to ints, and them > comparing them to your enums, and you get a lot of compilers errors if yo= u > do the wrong castings when activating all of warning and error compiler > flags. Add to the mix templates, autos, and so on. > > So, why not just allow overload conversion operators externally but only > for enums classes, while disallowing them for other types? > > template > operator integral_t(table1_cols t) > { > static_assert(std::is_integral(), "Only to integrals!!"); > return static_cast(t); > } > > > > or at least, allow implicit conversions to the underlying type, or add to > the language a syntax resource to activate implicit casts to the underlyi= ng > type (consequently, its user responsability to define which is the most > common integral underlying type that you will cast to). > > Strong types enums were added for a reason, but sometimes you have a > well-defined semantics and a controled-used of your enums that makes the > usual risks of using raw enums unnecesary (but you still wants some of th= e > features of strong enums), and I think such a language tool can save you = a > lot of time. > > -- > 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/b9b24701-fd4e-411b- > 91e1-608bba06fe96%40isocpp.org > > . > --=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/CAFQaeCAy5KuE9D%2BtDq4maTgnG90oBDRqxfU_t0-A8YwTc= 0W2nA%40mail.gmail.com. --f403045ef0dacf1b95055e6d4013 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I posted here previously about adding a 'std::und= erlying_cast' for enums.
People agreed with the concept, but = not the name (which is fine).

On Mon, Nov 20, 2017 at 4:59 PM, Aar=C3=B3n Bueno Villare= s <abv150ci@gmail.com> wrote:
Enum classes doesn't allow, by default, implicit = conversion, not even to the underlying type:

enum class= A : int { zero, one };
voi= d foo(int) {}

int main() = { foo(A::zero= ); }

a= nd that is a good thing, but sometimes, you need a enum class only to avoid= name colissions, for example:

enum class table1_cols { id, name = };
enum class table2_= cols { id, address };

If table1_cols and table2_cols w= ere raw enums, there would be a colission between both id named values, sin= ce they have global namespace scope, but your intention is to treat them as= raw enums to pass to other functions receiving integers, comparing them, u= sing them on switchs, and so on, but still be forced to qualify its use wit= h enum_type::value syntax for security reasons.

Yo= u can of course create a parametrized class for enums with the suitable ove= rloads of comparision operators and conversions operators and constructors,= but then you have an extra layer of qualification when dealing with those = values (for example, enum_wrapper<table1_cols>(table1_cols::i= d), or just enum_wrapper(table1_cols::id)=C2=A0in C++17, bu= t I think that is an innecesary extra typing anyway.=C2=A0

I know that is not hard to just cast it using the C-notation, like= (int)table1_cols::id, but in certain situations you have a mix of i= nt, unsigneds, and enums, for example, because you use enums as indexes for= your own purposes (and thus you deal with std::size_t's) and interact = with third party libraries that uses ints (for example, model indexes), or = make temporary arithmetic operations with unsigneds that forces you to cast= them to ints, and them comparing them to your enums, and you get a lot of = compilers errors if you do the wrong castings when activating all of warnin= g and error compiler flags. Add to the mix templates, autos, and so on.=C2= =A0

So, why not just allow overload conversion ope= rators externally but only for enums classes, while disallowing them for ot= her types?

template<class integral_t<= /span>>
operator integral_t(table1_cols t)
{
= =C2=A0 =C2=A0 static_assert(std::is_integral<integral_t>(),= "Only to integrals!!");
=C2=A0 = =C2=A0 return static_cast<int&= gt;(t);
}


or at least, allow i= mplicit conversions to the underlying type, or add to the language a syntax= resource to activate implicit casts to the underlying type (consequently, = its user responsability to define which is the most common integral underly= ing type that you will cast to).

Strong types enum= s were added for a reason, but sometimes you have a well-defined semantics = and a controled-used of your enums that makes the usual risks of using raw = enums unnecesary (but you still wants some of the features of strong enums)= , and I think such a language tool can save you a lot of time.
<= span class=3D"HOEnZb">

--
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-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/b9b2= 4701-fd4e-411b-91e1-608bba06fe96%40isocpp.org.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAy5KuE9D= %2BtDq4maTgnG90oBDRqxfU_t0-A8YwTc0W2nA%40mail.gmail.com.
--f403045ef0dacf1b95055e6d4013-- .