220 35424 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: Tue, 21 Nov 2017 08:10:22 +0000 Lines: 318 Approved: news@gmane.org Message-ID: 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/alternative; boundary="f403045f3e0819fbb0055e79bc82" X-Trace: blaine.gmane.org 1511251829 7652 195.159.176.226 (21 Nov 2017 08:10:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Nov 2017 08:10:29 +0000 (UTC) Cc: "bop@gmb.dk" To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCR6HLXQUAORB4F6Z7IAKGQEJGR3LUQ@isocpp.org Tue Nov 21 09:10:20 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eH3dK-0001Ec-10 for gclcip-std-proposals@m.gmane.org; Tue, 21 Nov 2017 09:10:18 +0100 Original-Received: by mail-yw0-f197.google.com with SMTP id j198sf5455838ywg.12 for ; Tue, 21 Nov 2017 00:10:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1511251825; cv=pass; d=google.com; s=arc-20160816; b=ZASuuFHcvzHo6cGNG4YmmVma0/ioY0iLbRl4kTZxuLdMHnevdvXhUDqLzbrHv3b9n9 /3CQ3GDmB/EmOEUBdeQ4a86EFvfIkTYU9oka67rvaY+LFIifFUuRZ9ymY8/3OU5rG45Z 1Q2U1++Qf1GCR+e67mmYlItpE8pDjb5XeGbJM3SaX2xCuAm8cetzHBARqrZQB8o4J02h 2c7EAN37Dk/GrAim+OVv3pbB3xWzDMhbU13Q6ApuqMcoYFj86kJ8rF2+joCu6YXA/JKy PqsBPAZued5jKRSQ8VR33EaSxFlsaVkqFU106QW0GEKE9cVlOsFbNCfSHuIRsvxxqB24 CEMw== 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:cc:to:subject:message-id :date:from:references:in-reply-to:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=CRqajRpdItXioQ6EXGISXT+muJULqJoflgOhS3EMQiE=; b=0UHcqicH81YM0zMit1XjzUNZE8N8w5V77u84Vq+r9XuJwf3NFp945AE74ky/0eeXSW qYsWYvbrYo0IN8JU5EDgnvfxUQqgE5IBNJ3V5QafSjd4Exuzvl6/ZCdEV4R6aNO79mLu l/lq5ZBd49iIrk55jH4PxxDkWhOU1GDjisJUgYK61iQ/Q1WjBFRLuuXlp4Xe6CuxHhgZ r4mdjQB46BHGWhFBTKGzkq9TWE5Egb3CUsr9Ny887zKI4vvrJS4McO/yt6ptW9L70aHP f/xZLqnIkRjnMwbjXtZLKiGi+29tDg1PeQTO5MpzaHWR/KQQdEBLAQP+ACH4FXDlTnmv +i9w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Up1r0X1U; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 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 :cc: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=CRqajRpdItXioQ6EXGISXT+muJULqJoflgOhS3EMQiE=; b=ma+Gr36BxBneI6HFH5eZLBrTr7odAD7BsTJclSTQokrL4s0xohgneWNppklVFimZYe USix+gsq7BV20jdoUD9NmIE53TlrTu5lZBzPOpo0STUKFrz5l31nUDSVM7czV+qQ6mAF OUpfTPgz0guMMabAyoqi0+gDAfBXN8VZEtxbncCMtTNAXItO3GN5fUKVRE6UTfTHx+sL MYTn6Di+RisY6UByd6wJ3a9sV93ylwPvmVxE+oCcQeWhSIV+yFQw4jJYcECOsqq4izcd mvRCVZr7enOOEG6pe8ryye5n3seg9TZk5ffNrWAoPS5kidE1E/bRLL1gbClqwpP9JFFf dlUQ== 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:cc: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=CRqajRpdItXioQ6EXGISXT+muJULqJoflgOhS3EMQiE=; b=J7hkN29/+ZpcKus0ZK0DR+74vJ6MwFkDSctFlnH6HJ6q9+3UDFTFoJ/w8ZulQfLO3R 497KdVbFOw4Q4vGe/K1X4QkPVJoxw64/AFmO3Ktqu8yfWnF1+PB2M+OET6QWCmFzfgG5 8IMTB2T4dJkMxfJqQgv5a7YkCCTwznC6pO8cpFMzND/DWgh/Qc9RooeXbcLnzsYgKTvZ lAGYKR/CbT1czdSBAxl0s2kTDPBjrL+vcycoCw0UrwXUENSxQmUXGhUphae/puRfDXU0 78idDm8c3jrW6zTR0AnPPidXJqQmXzLXKBLgKqyvXxNIYmrw/7tkCQBsP4l/S+ccaNu6 7F4A== X-Gm-Message-State: AJaThX6IH4wbEb4THyBYlxzLX1JMSHe9fsOEwXAPgGmQIL8a7izTAsmK AF8qm2OwE8qcMXHyoX9Mpe+ZIg== X-Google-Smtp-Source: AGs4zMb+J5tQDN5K1fpsXWtDoBeuOjo2T0UndrRTx42RXNjMqrNDmCnAKfgry3teh/+kmcj5SwkHdQ== X-Received: by 10.129.177.137 with SMTP id p131mr1421265ywh.139.1511251825112; Tue, 21 Nov 2017 00:10:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.129.125.133 with SMTP id y127ls28831ywc.18.gmail; Tue, 21 Nov 2017 00:10:23 -0800 (PST) X-Received: by 10.129.56.8 with SMTP id f8mr10087950ywa.468.1511251823921; Tue, 21 Nov 2017 00:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511251823; cv=none; d=google.com; s=arc-20160816; b=WANtFrQm4qWJRxX065jMYX7mv7171N/tW6q36uYhqWR3QMHJYCT1QgvBN0jXeiKHtf W/eEFkh/lRquZnz5W5KFuKGiOVdO7WM+GtFjmSpYPX1Lf6uy67LlL0KS2yZxhKqj+jU2 5UNCCcSNccCeZSOyyf1RdCqRbwfDKat+gHzs4X8z2rVjOXZ7KkiJDVDUd61Ue1Rgch7c x4TcxMzA5hO00d4nK3xSiyxrqS8q1bTUaeCL/cHp0BbnjG2XUkHoJuK4qEzUZNCH9o+5 0sFIJQcQiY/t+6mteNt7dTjhkIDj8ZYMKUpsHBXRD65IEzwdcckoI0GO9Ah0ycDxYb+M H8xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=2W4D6XYIw3HPebHPGelaw1NirjJvOGLwtC6iWmXnon0=; b=oMa6Ln/F6wHUlXP/B2CAGX+wt0dc0TTjk0JniTra5n3uavD6NTfuw6vO98f7R6prrl XYOlfxrKmXoK6jMv7zIDFHgUuZkCgrwuM6iHG1ch44GWjp/ERSfEhpW2q2iDZJ+ZdC4/ HRLjuKLrfFbm0wNBCSv2rYpqV6UuBVOJXSJP/RE5ItgyTRoJhfku093ALKvvl1umnLUn 75ZZfVk5srRDRKUbC5AkYdDaS8xLwLWYaEV/c25ONyXQD56SnhSMAG6SOv5s3oh1A4Mu AYq4LKmC7HXr6mMr+0ueNi7H1PWWp/i7DnPJshtXaVxQnoe+u0VbJUQVsrqYaKtNNJw7 1iHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Up1r0X1U; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 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-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id x123sor4505875ybg.9.2017.11.21.00.10.23 for (Google Transport Security); Tue, 21 Nov 2017 00:10:23 -0800 (PST) Received-SPF: pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.37.179.1 with SMTP id l1mr10342277ybj.25.1511251823425; Tue, 21 Nov 2017 00:10:23 -0800 (PST) Original-Received: by 10.37.183.200 with HTTP; Tue, 21 Nov 2017 00:10:22 -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=Up1r0X1U; spf=pass (google.com: domain of james.a.cooper@gmail.com designates 209.85.220.65 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:35424 Archived-At: --f403045f3e0819fbb0055e79bc82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, November 20, 2017, Nicol Bolas wrote: > On Monday, November 20, 2017 at 4:27:30 PM UTC-5, Bo Persson wrote: >> >> On 2017-11-20 19:30, 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: >> > > >> > > >> > > On Monday, 20 November 2017 18:18:36 UTC+1, Nicol Bolas wrote: >> > > >> > > >> > > >> > > On Monday, November 20, 2017 at 11:59:03 AM UTC-5, Aar=C3= =B3n >> Bueno >> > > Villares wrote: >> > > >> > > Enum classes doesn't allow, by default, implicit >> > conversion, not >> > > even to the underlying type: >> > > >> > > | >> > > enumclassA :int{zero,one }; >> > > voidfoo(int){} >> > > >> > > intmain(){foo(A::zero);} >> > > | >> > > >> > > and that is a good thing, but sometimes, you need a enu= m >> > class >> > > only to avoid name colissions, for example: >> > > >> > > | >> > > enumclasstable1_cols {id,name }; >> > > enumclasstable2_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, >> > > >> > > >> > > If they were unscoped enums, you could /still/ refer to the= m >> as >> > > `table1_cols::id` and `table2_cols::id`. So just do that. >> > > >> > > >> > > It gives you (g++ at least) a compiler error because `id` has >> been >> > > redeclared. >> > > >> > >> > So disable that warning, or put the unscoped enum inside its own >> scope >> > (namespace or struct). >> > >> > namespace table1_cols { enum {id,name}; }; >> > >> > >> > But then, it's difficult to use them as a typed quantity. That is, >> > making a variable of type `table1_cols` isn't possible, since it's a >> > namespace. You'd have to use `decltype` gymnastics. >> >> This was to solve one problem - implicit conversion to ints. >> >> If you want a type name for this, you can name the enum and use that as >> a type >> >> namespace table1 { enum cols {id,name}; }; >> >> using table1_cols =3D table1::cols; >> >> >> > >> > 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 facilitat= e >> > that corner case; we should make it as painful as possible to >> > /discourage/ design which leads to that. >> > >> >> Yes, it is a problem when you use enum class to try to make the type not >> implicitly convertible to an integer, except sometimes. It is hard to >> write the code for "implicitly convertible only when I want it to be". >> > > I think the problem isn't that the values aren't implicitly convertible. > It's that explicit conversion to the underlying type is a gigantic eyesor= e. > So... let's solve that problem: let's have a way to explicitly convert an > enumerator to the underlying type, only without the verbosity of > `static_cast`. A simple solution is to add an operator for that. Or rathe= r, > use an existing operator for this, since this is totally not worth creati= ng > an operator for: > > enum class blah {...}; > > auto operator+(blah b) {return static_cast>(= b > );} > > Then, when you want to convert an enumerator into the underlying type, yo= u > just use `+`. Granted, `+` may not be the best unary operator to use here= , > but feel free to use whatever seems natural. > > You could even wrap such a definition in a macro, allowing it to be reuse= d > for any enumerator type you would like. > That won't be very helpful when you want to write an enum value to an ostream (ambiguous overloads) Want to write an enum to a binary file? You need to know the correct size. Now, you could add new overloads for every enum you have, but hopefully we can all agree that that would be daft. The language needs to make this easy --=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/CAFQaeCACa7Vn55v_wVcPDh%3Dm%3DfMzoOvwLh4Dn%2Bjos= wx%3DPV9CQg%40mail.gmail.com. --f403045f3e0819fbb0055e79bc82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Monday, November 20, 2017, Nicol Bolas <jmckesson@gmail.com> wrote:
On Monday, November 20, 2017 at 4:27:30 PM U= TC-5, Bo Persson wrote:
On 2017-11-2= 0 19:30, Nicol Bolas wrote:
> On Monday, November 20, 2017 at 1:19:55 PM UTC-5, Bo Persson wrote= :
>=20
> =C2=A0 =C2=A0 On 2017-11-20 18:36, Aar=C3=B3n Bueno Villares wrote= :
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> On Monday, 20 November 2017 18:18:36 UTC+= 1, Nicol Bolas wrote:
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 On Monday, November 20, 201= 7 at 11:59:03 AM UTC-5, Aar=C3=B3n Bueno
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 Villares wrote:
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Enum classes = doesn't allow, by default, implicit
> =C2=A0 =C2=A0 conversion, not
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 even to the u= nderlying type:
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumclassA :i= nt{zero,one };
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 voidfoo(int){= }
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 intmain(){foo= (A::zero);}
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and that is a= good thing, but sometimes, you need a enum
> =C2=A0 =C2=A0 class
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 only to avoid= name colissions, for example:
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumclasstabl= e1_cols {id,name };
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumclasstabl= e2_cols {id,address };
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 If table1_col= s and table2_cols were raw enums, there
> =C2=A0 =C2=A0 would be a
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 colission bet= ween both id named values, since they have
> =C2=A0 =C2=A0 global
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace sco= pe,
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 If they were unscoped enums= , you could /still/ refer to them as
> =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 `table1_cols::id` and `tabl= e2_cols::id`. So just do that.
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0>
> =C2=A0 =C2=A0 =C2=A0> It gives you (g++ at least) a compiler er= ror because `id` has been
> =C2=A0 =C2=A0 =C2=A0> redeclared.
> =C2=A0 =C2=A0 =C2=A0>
>=20
> =C2=A0 =C2=A0 So disable that warning, or put the unscoped enum in= side its own scope
> =C2=A0 =C2=A0 (namespace or struct).
>=20
> =C2=A0 =C2=A0 namespace table1_cols { enum {id,name}; };
>=20
>=20
> But then, it's difficult to use them as a typed quantity. That= is,=20
> making a variable of type `table1_cols` isn't possible, since = it's a=20
> namespace. You'd have to use `decltype` gymnastics.

This was to solve one problem - implicit conversion to ints.

If you want a type name for this, you can name the enum and use that as= =20
a type

=C2=A0 =C2=A0 =C2=A0namespace table1 { enum cols {id,name}; };

=C2=A0 =C2=A0 =C2=A0using table1_cols =3D table1::cols;


>=20
> Personally, I try to design things so that either we're talkin= g about an=20
> integer or we aren't. The OP's problem only arises when yo= u 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 f= acilitate=20
> that corner case; we should make it as painful as possible to=20
> /discourage/ design which leads to that.
>

Yes, it is a problem when you use enum class to try to make the type no= t=20
implicitly convertible to an integer, except sometimes. It is hard to= =20
write the code for "implicitly convertible only when I want it to = be".

I think the problem isn't= that the values aren't implicitly convertible. It's that explicit = conversion to the underlying type is a gigantic eyesore. So... let's so= lve that problem: let's have a way to explicitly convert an enumerator = to the underlying type, only without the verbosity of `static_cast`. A simp= le solution is to add an operator for that. Or rather, use an existing oper= ator for this, since this is totally not worth creating an operator for:

enum class blah = {...};

= auto operator+= (blah b= ) {return static_cast= <std= ::underlying_type_t<blah>>(= b);}

Then, when you want to convert an enumerator into the u= nderlying type, you just use `+`. Granted, `+` may not be the best unary op= erator to use here, but feel free to use whatever seems natural.

You= could even wrap such a definition in a macro, allowing it to be reused for= any enumerator type you would like.

<= div>
That won't be very helpful when you want to write an= enum value to an ostream (ambiguous overloads)
Want to write an enum = to a binary file? You need to know the correct size.

Now= , you could add new overloads for every enum you have, but hopefully we can= all agree that that would be daft.
The language needs to make this= easy


--
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/CAFQaeCAC= a7Vn55v_wVcPDh%3Dm%3DfMzoOvwLh4Dn%2Bjoswx%3DPV9CQg%40mail.gmail.com. --f403045f3e0819fbb0055e79bc82-- .