220 35419 <9b3ceef2-c0a7-4502-90d4-05092c45231b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Aar=C3=B3n_Bueno_Villares?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allow out-of-class operator overloading for enum classes Date: Mon, 20 Nov 2017 10:53:49 -0800 (PST) Lines: 208 Approved: news@gmane.org Message-ID: <9b3ceef2-c0a7-4502-90d4-05092c45231b@isocpp.org> References: <608409c3-7708-4024-8ca5-8ecd566ca4a9@isocpp.org> <990fd030-20de-4bec-b11f-b43f9338667c@isocpp.org> <40465af3-4752-44b9-9367-cf2d1c41a335@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6539_801192191.1511204029758" X-Trace: blaine.gmane.org 1511204034 27139 195.159.176.226 (20 Nov 2017 18:53:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Nov 2017 18:53:54 +0000 (UTC) Cc: bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCP4374NRYKBBPWJZTIAKGQEYEMKU7Q@isocpp.org Mon Nov 20 19:53:49 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGrCS-0006S5-Me for gclcip-std-proposals@m.gmane.org; Mon, 20 Nov 2017 19:53:44 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id k82sf6142909vkd.11 for ; Mon, 20 Nov 2017 10:53:52 -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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=8x9OTDTCTthQ79XPIWy4TR5YBO5rGSGCetAtsfolbK4=; b=qdyq404BfVwjtMceLql5Y8Cht9WGlcOj3GUwEGvg3uHdW47x7fGMGCdk6Xm6CXy/eO GTC1O3mdEkL7zjeRb8I9vgoCUNY6XXDyrR7raqoS4sU3TQ+1nCLfWFnFT8ffWORW+lCF MVyN/1GF9tPq99imZND/B4nejZ1YDE7CcHVnV01CgSId1JBI4oO+1HzX3C90bc4oM587 aQsk3dbYGKtQDRAwia3XX250NpidKsYJU8egSXdlfuXcMIjU23XVUANipiAJgQuJ2bx6 HHxMMzJ2cBjJMhhE/Xn8Z2+8gXCMwl2awiEgw8rQsWCeMj5K7g8rRcv1CfsBW6jcUEQf WZqA== 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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=8x9OTDTCTthQ79XPIWy4TR5YBO5rGSGCetAtsfolbK4=; b=CwESJc4jql4/oy5rluhM9xlPt4zeztO4qLPtykJVz62vM3I13hB89yY4xpQREyopyR mtN2SQ6XXTD6WxsummDYBGxDLIfNKnLXUF+PQQT2q4tjma+0s71iOriyhrMvdj+g7xjw iL+ACGc9F9ljsuFfQDh/zrHTfnQ8wpa31t5g9zbJmbbNGOTQBeXpWQkHoOxxnOkLOjsP lxL1xxtfFTJvwm1x7eBxuXDvJWh/u8jPM0gI/qNU6BbAZgwSBzY35PC5nSRGluLau6f8 uMu33v26BrrQ435kGgUWS0MyRXJVvoIuwLK/HL8OXHOS5T8tm6L/WFnyvHmyxmWomrZp wSgw== 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=8x9OTDTCTthQ79XPIWy4TR5YBO5rGSGCetAtsfolbK4=; b=tizY6+gtx0W90+UaXc4C/zjzs3F1fHh8q/pEnS397pHe/QFG12l9HkIbW/Alf5MwnN AG+A7mxX+ILCgrm7jOH9dPmkja8CXE0cg5dN6Nx08zPvVz+5RJYpQoIsN6r9qbqOX3xb puNEgdGHzWiIRDeDRtH53zeMV5YrOUZdRPaRWvmSjMjgbIwNosEMue9HSaiwx927eSRx 8z6g/LHeTDTU+ojMptKibwfVi0LDBIa6//KqTqcjzsLVrHhoCumjlkF1xleGHxClPY/R tB15r+Wcn8XDTuZb3NWjzbSu+DSmJpRUm2uKP5Xf9CFbxhF6G5NzlQI/OoOsr29Pnahg qkCw== X-Gm-Message-State: AJaThX4NsdRCjEP8xlYTaK5a9xzT/CeuThOri2JMxRgLNRSRAEXGxoH7 sAlYPQNUgA9YeP7PgIyCJMZhLA== X-Google-Smtp-Source: AGs4zMYAc+pZ945TzZNlGiDMohNit8S97VcaMfxk/tjniXXlGqUXUaPLdxyFn0hZOAWHDcfLaKLVSg== X-Received: by 10.31.235.1 with SMTP id j1mr6925573vkh.16.1511204031807; Mon, 20 Nov 2017 10:53:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.55.141 with SMTP id q13ls3353751uaq.14.gmail; Mon, 20 Nov 2017 10:53:50 -0800 (PST) X-Received: by 10.31.94.198 with SMTP id s189mr1318766vkb.9.1511204030260; Mon, 20 Nov 2017 10:53:50 -0800 (PST) In-Reply-To: <40465af3-4752-44b9-9367-cf2d1c41a335@isocpp.org> X-Original-Sender: abv150ci@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:35419 Archived-At: ------=_Part_6539_801192191.1511204029758 Content-Type: multipart/alternative; boundary="----=_Part_6540_724248751.1511204029759" ------=_Part_6540_724248751.1511204029759 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable By it becomes a problem when dealing with third-party libraries. Sometimes= =20 is a bit tricky to adapt third-party libraries to your own designs. Because of the risks of plain enums and the restrictions of strong-types=20 enums, in my experience, the only comfortable and adecuate use case for=20 using enums is to use them as flags. Any other use of enums have caused=20 troubles of some kind to me. It would be awesome to make enums more class-alike. On Monday, 20 November 2017 19:30:53 UTC+1, Nicol Bolas wrote: > > On Monday, November 20, 2017 at 1:19:55 PM UTC-5, Bo Persson wrote: >> >> On 2017-11-20 18:36, Aar=C3=B3n Bueno Villares wrote:=20 >> >=20 >> >=20 >> > On Monday, 20 November 2017 18:18:36 UTC+1, Nicol Bolas wrote:=20 >> >=20 >> >=20 >> >=20 >> > On Monday, November 20, 2017 at 11:59:03 AM UTC-5, Aar=C3=B3n Buen= o=20 >> > Villares wrote:=20 >> >=20 >> > Enum classes doesn't allow, by default, implicit conversion,= =20 >> not=20 >> > even to the underlying type:=20 >> >=20 >> > |=20 >> > enumclassA :int{zero,one };=20 >> > voidfoo(int){}=20 >> >=20 >> > intmain(){foo(A::zero);}=20 >> > |=20 >> >=20 >> > and that is a good thing, but sometimes, you need a enum class= =20 >> > only to avoid name colissions, for example:=20 >> >=20 >> > |=20 >> > enumclasstable1_cols {id,name };=20 >> > enumclasstable2_cols {id,address };=20 >> > |=20 >> >=20 >> > If table1_cols and table2_cols were raw enums, there would be = a=20 >> > colission between both id named values, since they have global= =20 >> > namespace scope,=20 >> >=20 >> >=20 >> > If they were unscoped enums, you could /still/ refer to them as=20 >> > `table1_cols::id` and `table2_cols::id`. So just do that.=20 >> >=20 >> >=20 >> > It gives you (g++ at least) a compiler error because `id` has been=20 >> > redeclared.=20 >> >=20 >> >> So disable that warning, or put the unscoped enum inside its own scope= =20 >> (namespace or struct).=20 >> >> namespace table1_cols { enum {id,name}; };=20 >> > > But then, it's difficult to use them as a typed quantity. That is, making= =20 > a variable of type `table1_cols` isn't possible, since it's a namespace.= =20 > You'd have to use `decltype` gymnastics. > > Personally, I try to design things so that either we're talking about an= =20 > integer or we aren't. The OP's problem only arises when you have an=20 > enumeration that you sometimes use as an enum and sometimes use as an=20 > integer. I don't think we should make language facilities to facilitate= =20 > that corner case; we should make it as painful as possible to *discourage= *=20 > design which leads to that. > > > --=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/9b3ceef2-c0a7-4502-90d4-05092c45231b%40isocpp.or= g. ------=_Part_6540_724248751.1511204029759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By it becomes a problem when dealing with third-party libr= aries. Sometimes is a bit tricky to adapt third-party libraries to your own= designs.

Because of the risks of plain enums and the re= strictions of strong-types enums, in my experience, the only comfortable an= d adecuate use case for using enums is to use them as flags. Any other use = of enums have caused troubles of some kind to me.

= It would be awesome to make enums more class-alike.

On Monday, = 20 November 2017 19:30:53 UTC+1, Nicol Bolas wrote:
On Monday, November 20, 2017 at 1:19= :55 PM UTC-5, Bo Persson wrote:
On 2= 017-11-20 18:36, Aar=C3=B3n Bueno Villares wrote:
>=20
>=20
> On Monday, 20 November 2017 18:18:36 UTC+1, Nicol Bolas wrote:
>=20
>=20
>=20
> =C2=A0 =C2=A0 On Monday, November 20, 2017 at 11:59:03 AM UTC-5, A= ar=C3=B3n Bueno
> =C2=A0 =C2=A0 Villares wrote:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Enum classes doesn't allow, by def= ault, implicit conversion, not
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 even to the underlying type:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumclassA :int{zero,one };
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 voidfoo(int){}
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 intmain(){foo(A::zero);}
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and that is a good thing, but sometime= s, you need a enum class
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 only to avoid name colissions, for exa= mple:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumclasstable1_cols {id,name };
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumclasstable2_cols {id,address };
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 If table1_cols and table2_cols were ra= w enums, there would be a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 colission between both id named values= , since they have global
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace scope,
>=20
>=20
> =C2=A0 =C2=A0 If they were unscoped enums, you could /still/ refer= to them as
> =C2=A0 =C2=A0 `table1_cols::id` and `table2_cols::id`. So just do = that.
>=20
>=20
> It gives you (g++ at least) a compiler error because `id` has been= =20
> redeclared.
>=20

So disable that warning, or put the unscoped enum inside its own scope= =20
(namespace or struct).

namespace table1_cols { enum {id,name}; };

But then, it's difficult to use th= em as a typed quantity. That is, making a variable of type `table1_cols` is= n't possible, since it's a namespace. You'd have to use `declty= pe` gymnastics.

Personally, I try to design things= so that either we're talking about an integer or we aren't. The OP= 's problem only arises when you have an enumeration that you sometimes = use as an enum and sometimes use as an integer. I don't think we should= make language facilities to facilitate that corner case; we should make it= as painful as possible to discourage design which leads to that.


--
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/9b3ceef2-c0a7-4502-90d4-05092c45231b= %40isocpp.org.
------=_Part_6540_724248751.1511204029759-- ------=_Part_6539_801192191.1511204029758-- .