Topic: Explicitly-defaulted enumeration operators
Author: David Krauss <potswa@gmail.com>
Date: Tue, 18 Mar 2014 10:17:24 +0800
Raw View
--Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
A generic unary operator+ for a scoped enumeration looks something like thi=
s:
template< typename e >
constexpr auto operator + ( e v )
noexcept (( typename std::enable_if<
enum_traits< e >::enum_trait_numeric::value
>::type (), true ))
{ return + static_cast< typename std::underlying_type< e >::type >( v )=
; }
This is a fair amount of boilerplate. Consistency with integral promotion v=
iz the built-in operator, and noexcept, are easy to miss.=20
It would promote ease of use and correctness to allow explicitly-defaulted =
definitions of the operators
E operator @ ( E, E ) // @ may be +, -, *, /, %, |, &, ^
E & operator @=3D ( E &, E ) // @ may be +, -, *, /, %, |, &, ^
E operator @ ( E, int ) // @ may be <<, >>
E & operator @=3D ( E &, int ) // @ may be <<, >>
E operator @ ( E ) // @ may be -, ~
T operator + ( E )
bool operator ! ( E )
where E is an enumeration type and T is the result of integral promotions o=
n its underlying type. The implicit definition should cast the operands to =
the underlying type, perform the operation, and cast back to the operand ty=
pe if necessary.
These operators cover enumerations behaving as bitsets or integers, which s=
eem to be on firm ground as acceptable use cases. There is no provision for=
adding a (non-enumerator) numeric displacement value to an enumerator that=
is not number-like.
operator+, which I used as an example, may be idiomatically used as the "pr=
omotion operator" and I've suggested different type-semantics from the othe=
r unary arithmetic operators, which could be contentious.
Has there already been a proposal along these lines?
An alternative approach would be to add generic operator overloads and trai=
ts to the library (like the above utility), but this wouldn't work for the =
same reason std::relops doesn't: there's no way to ADL-associate a user-def=
ined type with a function in std::.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">A generic unary <=
font face=3D"Courier">operator+</font> for a scoped enumeration looks somet=
hing like this:<div><br></div><div><div><font face=3D"Courier">template<=
typename e ></font></div><div><font face=3D"Courier">constexpr auto ope=
rator + ( e v )</font></div><div><font face=3D"Courier"> noexc=
ept (( typename std::enable_if<</font></div><div><font face=3D"Courier">=
 =
; enum_traits< e >::enum_trait_numeric::value</font></di=
v><div><font face=3D"Courier"> &nb=
sp; >::type (), true ))</font></div><div><font face=3D"Courier">&=
nbsp; { return + static_cast< typename std::underlying_type< e=
>::type >( v ); }</font></div></div><div><br></div><div>This is a fa=
ir amount of boilerplate. Consistency with integral promotion viz the built=
-in operator, and <font face=3D"Courier">noexcept</font>, are easy to miss.=
</div><div><br></div><div>It would promote ease of use and correctnes=
s to allow explicitly-defaulted definitions of the operators</div><div><br>=
</div><div><font face=3D"Courier"> E operator @ ( E, E ) // @ =
may be +, -, *, /, %, |, &, ^</font></div><div><div><font face=3D"Couri=
er"> E & operator @=3D ( E &, E ) // @ may be +, -, *,=
/, %, |, &, ^</font></div><div></div><div><font face=3D"Courier"> =
; E operator @ ( E, int ) // @ may be <<, >></font></div=
><div></div><div><font face=3D"Courier"> E & operator @=3D=
( E &, int ) // @ may be <<, >></font></div><div></div><di=
v><span style=3D"font-family: Courier;"> E operator @ ( E ) //=
@ may be -, ~</span></div></div><div><div></div><div><span style=3D"font-f=
amily: Courier;"> T operator + ( E )</span></div><div></div><d=
iv><span style=3D"font-family: Courier;"> bool operator ! ( E =
)</span></div></div><div><span style=3D"font-family: Courier;"><br></span><=
/div><div>where E is an enumeration type and T is the result of integral pr=
omotions on its underlying type. The implicit definition should cast the op=
erands to the underlying type, perform the operation, and cast back to the =
operand type if necessary.</div><div><br></div><div>These operators cover e=
numerations behaving as bitsets or integers, which seem to be on firm groun=
d as acceptable use cases. There is no provision for adding a (non-enumerat=
or) numeric displacement value to an enumerator that is not number-like.</d=
iv><div><br></div><div><font face=3D"Courier">operator+</font>, which I use=
d as an example, may be idiomatically used as the “promotion operator=
” and I’ve suggested different type-semantics from the other un=
ary arithmetic operators, which could be contentious.</div><div><br></div><=
div>Has there already been a proposal along these lines?</div><div><br></di=
v><div>An alternative approach would be to add generic operator overloads a=
nd traits to the library (like the above utility), but this wouldn’t =
work for the same reason <font face=3D"Courier">std::relops</font> doesn&rs=
quo;t: there’s no way to ADL-associate a user-defined type with a fun=
ction in <font face=3D"Courier">std::</font>.</div><div><br></div></bo=
dy></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 17 Mar 2014 21:00:45 -0700 (PDT)
Raw View
------=_Part_5768_29651277.1395115245252
Content-Type: text/plain; charset=UTF-8
Doesn't n3515
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf
cover what you are looking for?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5768_29651277.1395115245252
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Doesn't n3515 <a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2013/n3515.pdf">http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2013/n3515.pdf</a><br>cover what you are looking for?<br><div sty=
le=3D"word-wrap:break-word"><div><br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5768_29651277.1395115245252--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 18 Mar 2014 12:06:31 +0800
Raw View
--Apple-Mail=_925D69B6-4227-412D-A568-BEB6F354E622
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-18, at 12:00 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> Doesn't n3515 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf
> cover what you are looking for?
It proposes a feature that would supersede some uses of enumerations, but even if it is adopted, the problem of correct usage of enumerations would still remain.
A bitfield-like enumeration class wouldn't want to define addition and subtraction, except maybe as bitwise operations OR and ANDNOT. Not every enumeration with operators wants to be an opaque typedef.
Thanks for the tip, though! Was that proposal recommended for future study?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_925D69B6-4227-412D-A568-BEB6F354E622
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–18, at 12:00 PM, Matheus Izvekov <<a href=3D"mailto:mizve=
kov@gmail.com">mizvekov@gmail.com</a>> wrote:</div><br class=3D"Apple-in=
terchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Doesn't n3515=
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.p=
df">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf</a><b=
r>cover what you are looking for?<br></div></blockquote><div><br></div><div=
>It proposes a feature that would supersede some uses of enumerations, but =
even if it is adopted, the problem of correct usage of enumerations would s=
till remain.</div></div><br><div>A bitfield-like enumeration class wouldn&r=
squo;t want to define addition and subtraction, except maybe as bitwise ope=
rations OR and ANDNOT. Not every enumeration with operators wants to be an =
opaque typedef.</div><div><br></div><div>Thanks for the tip, though! Was th=
at proposal recommended for future study?</div><div><br></div></body></html=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_925D69B6-4227-412D-A568-BEB6F354E622--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 17 Mar 2014 21:19:12 -0700 (PDT)
Raw View
------=_Part_796_29457299.1395116352714
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 18, 2014 1:06:31 AM UTC-3, David Krauss wrote:
>
>
> It proposes a feature that would supersede some uses of enumerations, but=
=20
> even if it is adopted, the problem of correct usage of enumerations would=
=20
> still remain.
>
> A bitfield-like enumeration class wouldn=E2=80=99t want to define additio=
n and=20
> subtraction, except maybe as bitwise operations OR and ANDNOT. Not every=
=20
> enumeration with operators wants to be an opaque typedef.
>
Actually, the feature as proposed there would allow you to default and=20
delete operator definitions, so you could have what you want, an int opaque=
=20
alias which has operator+ deleted, and so you can't do addition.
=20
>
> Thanks for the tip, though! Was that proposal recommended for future stud=
y?
>
>
Sorry, I don't know. I don't think any subsequent paper was published=20
saying what was discussed wrt to it.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_796_29457299.1395116352714
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, March 18, 2014 1:06:31 AM UTC-3, David Kra=
uss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-w=
rap:break-word"><br><div><div>It proposes a feature that would supersede so=
me uses of enumerations, but even if it is adopted, the problem of correct =
usage of enumerations would still remain.</div></div><br><div>A bitfield-li=
ke enumeration class wouldn=E2=80=99t want to define addition and subtracti=
on, except maybe as bitwise operations OR and ANDNOT. Not every enumeration=
with operators wants to be an opaque typedef.</div></div></blockquote><div=
><br>Actually, the feature as proposed there would allow you to default and=
delete operator definitions, so you could have what you want, an int opaqu=
e alias which has operator+ deleted, and so you can't do addition.<br> =
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap=
:break-word"><div><br></div><div>Thanks for the tip, though! Was that propo=
sal recommended for future study?</div><div><br></div></div></blockquote><d=
iv><br>Sorry, I don't know. I don't think any subsequent paper was publishe=
d saying what was discussed wrt to it.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_796_29457299.1395116352714--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 18 Mar 2014 12:29:46 +0800
Raw View
--Apple-Mail=_59B47583-253A-4CC5-808C-AFB17D9AAFE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-03-18, at 12:19 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
>=20
> On Tuesday, March 18, 2014 1:06:31 AM UTC-3, David Krauss wrote:
>=20
> It proposes a feature that would supersede some uses of enumerations, but=
even if it is adopted, the problem of correct usage of enumerations would =
still remain.
>=20
> A bitfield-like enumeration class wouldn't want to define addition and su=
btraction, except maybe as bitwise operations OR and ANDNOT. Not every enum=
eration with operators wants to be an opaque typedef.
>=20
> Actually, the feature as proposed there would allow you to default and de=
lete operator definitions, so you could have what you want, an int opaque a=
lias which has operator+ deleted, and so you can't do addition.
Oh, now I see. It's a bit of a radical approach.
The problem is that for "custom scalar" types we sometimes want intrinsical=
ly named values (enumerators) for things like bitsets, but other times we w=
ant floating-point underlying type, which is incompatible with named values=
or often any specific values at all.
Perhaps now with opaque enum declarations, the use cases can be reconciled =
by allowing floating-point enumerations with the caveat that no enumerators=
are allowed. Or perhaps the lack of implicit operators (and comparability =
to the underlying FP type) already provides sufficient safety and the langu=
age is ready for floating-point enumerations.
Anyway, my instinct is that building on the existing enumeration framework =
would be simpler than starting with typedefs. I should contact Walter, than=
ks again.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_59B47583-253A-4CC5-808C-AFB17D9AAFE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03–18, at 12:19 PM, Matheus Izvekov <<a href=3D"mailto:mizve=
kov@gmail.com">mizvekov@gmail.com</a>> wrote:</div><br class=3D"Apple-in=
terchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><br>On Tuesda=
y, March 18, 2014 1:06:31 AM UTC-3, David Krauss wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><br><div>It pr=
oposes a feature that would supersede some uses of enumerations, but even i=
f it is adopted, the problem of correct usage of enumerations would still r=
emain.</div><br><div>A bitfield-like enumeration class wouldn’t want =
to define addition and subtraction, except maybe as bitwise operations OR a=
nd ANDNOT. Not every enumeration with operators wants to be an opaque typed=
ef.</div></div></blockquote><div><br>Actually, the feature as proposed ther=
e would allow you to default and delete operator definitions, so you could =
have what you want, an int opaque alias which has operator+ deleted, and so=
you can't do addition.<br></div></div></blockquote><div><br></div><div>Oh,=
now I see. It’s a bit of a radical approach.</div><div><br></div><di=
v>The problem is that for “custom scalar” types we sometimes wa=
nt intrinsically named values (enumerators) for things like bitsets, but ot=
her times we want floating-point underlying type, which is incompatible wit=
h named values or often any specific values at all.</div><div><br></div><di=
v>Perhaps now with opaque enum declarations, the use cases can be reconcile=
d by allowing floating-point enumerations with the caveat that no enumerato=
rs are allowed. Or perhaps the lack of implicit operators (and comparabilit=
y to the underlying FP type) already provides sufficient safety and the lan=
guage is ready for floating-point enumerations.</div></div><br><div>Anyway,=
my instinct is that building on the existing enumeration framework would b=
e simpler than starting with typedefs. I should contact Walter, thanks agai=
n.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_59B47583-253A-4CC5-808C-AFB17D9AAFE7--
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 17 Mar 2014 21:42:13 -0700 (PDT)
Raw View
------=_Part_5788_26326251.1395117733424
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 18, 2014 1:29:46 AM UTC-3, David Krauss wrote:
>
>
> Oh, now I see. It=E2=80=99s a bit of a radical approach.
>
> The problem is that for =E2=80=9Ccustom scalar=E2=80=9D types we sometime=
s want=20
> intrinsically named values (enumerators) for things like bitsets, but oth=
er=20
> times we want floating-point underlying type, which is incompatible with=
=20
> named values or often any specific values at all.
>
> Perhaps now with opaque enum declarations, the use cases can be reconcile=
d=20
> by allowing floating-point enumerations with the caveat that no enumerato=
rs=20
> are allowed. Or perhaps the lack of implicit operators (and comparability=
=20
> to the underlying FP type) already provides sufficient safety and the=20
> language is ready for floating-point enumerations.
>
> Anyway, my instinct is that building on the existing enumeration framewor=
k=20
> would be simpler than starting with typedefs. I should contact Walter,=20
> thanks again.
>
>
Well, he doesn't say explicitly, but it seems Walter's approach would be=20
applicable to enum types just as well, or if not, could be easily extended=
=20
to cover that.
But I agree that enum's are currently too limited, being able to use any=20
literal type as underlying type of an enum would be uber cool :-)
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5788_26326251.1395117733424
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 18, 2014 1:29:46 AM UTC-3, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><div><div><br></div><div>Oh, now I see. It=E2=80=99s a bit of a=
radical approach.</div><div><br></div><div>The problem is that for =E2=80=
=9Ccustom scalar=E2=80=9D types we sometimes want intrinsically named value=
s (enumerators) for things like bitsets, but other times we want floating-p=
oint underlying type, which is incompatible with named values or often any =
specific values at all.</div><div><br></div><div>Perhaps now with opaque en=
um declarations, the use cases can be reconciled by allowing floating-point=
enumerations with the caveat that no enumerators are allowed. Or perhaps t=
he lack of implicit operators (and comparability to the underlying FP type)=
already provides sufficient safety and the language is ready for floating-=
point enumerations.</div></div><br><div>Anyway, my instinct is that buildin=
g on the existing enumeration framework would be simpler than starting with=
typedefs. I should contact Walter, thanks again.</div><div><br></div></div=
></blockquote><div><br>Well, he doesn't say explicitly, but it seems Walter=
's approach would be applicable to enum types just as well, or if not, coul=
d be easily extended to cover that.<br><br>But I agree that enum's are curr=
ently too limited, being able to use any literal type as underlying type of=
an enum would be uber cool :-)<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5788_26326251.1395117733424--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 18 Mar 2014 12:51:08 +0800
Raw View
On 2014-03-18, at 12:42 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> Well, he doesn't say explicitly, but it seems Walter's approach would be applicable to enum types just as well, or if not, could be easily extended to cover that.
Yeah, but it would be redundant. And you would lose the implicit/defaultable definitions because there would be no underlying operators.
> But I agree that enum's are currently too limited, being able to use any literal type as underlying type of an enum would be uber cool :-)
Hmm, that covers a lot. But it's a good idea, thanks!
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 17 Mar 2014 22:01:02 -0700 (PDT)
Raw View
------=_Part_796_10176964.1395118862444
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 18, 2014 1:51:08 AM UTC-3, David Krauss wrote:
>
>
> On 2014=E2=80=9303=E2=80=9318, at 12:42 PM, Matheus Izvekov <mizv...@gmai=
l.com<javascript:>>=20
> wrote:=20
>
> > Well, he doesn't say explicitly, but it seems Walter's approach would b=
e=20
> applicable to enum types just as well, or if not, could be easily extende=
d=20
> to cover that.=20
>
> Yeah, but it would be redundant. And you would lose the=20
> implicit/defaultable definitions because there would be no underlying=20
> operators.=20
>
>
Hmm, but suppose you could write something like this:
enum class flags : uint32_t {
foo =3D 1, bar =3D 2, baz =3D 4;
flags operator|(flags,flags) =3D default;
};
Seems all the machinery for this is in Walter's paper, but it would need a=
=20
new grammar rule for allowing ';' inside enum definitions.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_796_10176964.1395118862444
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, March 18, 2014 1:51:08 AM UTC-3, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 2014=E2=80=9303=E2=80=9318, at 12:42 PM, Matheus Izvekov <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"u_r0wc1okXsJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">mizv...@gmail.com</a>> wrote:
<br>
<br>> Well, he doesn't say explicitly, but it seems Walter's approach wo=
uld be applicable to enum types just as well, or if not, could be easily ex=
tended to cover that.
<br>
<br>Yeah, but it would be redundant. And you would lose the implicit/defaul=
table definitions because there would be no underlying operators.
<br>
<br></blockquote><div><br>Hmm, but suppose you could write something like t=
his:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><div dir=3D"ltr" style=3D"font-size: 13.2835px; font-famil=
y: monospace; left: 122.567px; top: 287.962px; transform: rotate(0deg) scal=
e(0.99626, 1); transform-origin: 0% 0% 0px;" data-angle=3D"0" data-font-nam=
e=3D"g_font_303_0" data-canvas-width=3D"39.85040118763447"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> flags </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> uint32_t </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br> foo </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> bar </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> baz </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">4</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> flags </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">|(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">flags</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">flags</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">d=
efault</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><div dir=3D"ltr" style=3D"font-size: 13.2835px; font-family: monospace;=
left: 122.567px; top: 383.603px; transform: rotate(0deg) scale(0.99626, 1)=
; transform-origin: 0% 0% 0px;" data-angle=3D"0" data-font-name=3D"g_font_3=
03_0" data-canvas-width=3D"15.940160475053789"><span style=3D"color: #660;"=
class=3D"styled-by-prettify">};</span></div></div></code></div><br> S=
eems all the machinery for this is in Walter's paper, but it would need a n=
ew grammar rule for allowing ';' inside enum definitions.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_796_10176964.1395118862444--
.
Author: Ross Smith <rosss@pharos.co.nz>
Date: Wed, 19 Mar 2014 09:20:02 +1300
Raw View
On 2014-03-18 17:19, Matheus Izvekov wrote:
>
> On Tuesday, March 18, 2014 1:06:31 AM UTC-3, David Krauss wrote:
>
> Thanks for the tip, though! Was that proposal recommended for future
> study?
>
> Sorry, I don't know. I don't think any subsequent paper was published
> saying what was discussed wrt to it.
There's an updated version, N3741. I don't know what it's current status is.
Ross Smith
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 19 Mar 2014 13:48:31 -0400
Raw View
On 2014-03-18 01:01, Matheus Izvekov wrote:
> Hmm, but suppose you could write something like this:
>
> enum class flags : uint32_t {
> foo = 1, bar = 2, baz = 4;
> flags operator|(flags,flags) = default;
> };
That would be awesome. In fact I have a 'to do' to suggest exactly this.
std::flags might cover that specific use case, but I also want to be
able to do things like:
enum class foo {
...values...
foo(std::string const*); // constructor
operator std::string(); // conversion operator
};
(These sorts of conversions already show up frequently, but right now
must be implemented as free functions; the ability to make them members
would be great.)
Something else I would really love to see though is using an enumeration
as an underlying ("base") type of an enumeration, e.g.:
enum class A { a1, a2, ... };
enum class B : A { b1, b2, ... };
B bb = B::a1; // legal; a1, etc. are in scope of B, inherited from A
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 19 Mar 2014 11:49:09 -0700
Raw View
Em qua 19 mar 2014, =E0s 13:48:31, Matthew Woehlke escreveu:
> Something else I would really love to see though is using an enumeration=
=20
> as an underlying ("base") type of an enumeration, e.g.:
>=20
> enum class A { a1, a2, ... };
> enum class B : A { b1, b2, ... };
>=20
> B bb =3D B::a1; // legal; a1, etc. are in scope of B, inherited from A
That would be very welcome. Multiple inheritance too.
It would solve some of the hacks I had to do for QUrl, when some functions=
=20
take only a subset of the flags. I could have split them in two separate=20
parameters, though.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Wed, 19 Mar 2014 15:37:12 -0700 (PDT)
Raw View
------=_Part_10_21988562.1395268632051
Content-Type: text/plain; charset=UTF-8
I made a reply to this thread but now it's gone and it says "This message
has been deleted."
Did someone accidentally delete it?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_10_21988562.1395268632051
Content-Type: text/html; charset=UTF-8
<div dir="ltr">I made a reply to this thread but now it's gone and it says "<span>This message has been deleted."<br><br>Did someone accidentally delete it?<br></span></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_10_21988562.1395268632051--
.
Author: Matthew Woehlke <matthew.woehlke@kitware.com>
Date: Wed, 19 Mar 2014 19:02:47 -0400
Raw View
(I'm leaving the entirety of Matheus text as something appears to have
eaten that message...)
On 2014-03-19 18:14, Matheus Izvekov wrote:
> On Wednesday, March 19, 2014 2:48:31 PM UTC-3, Matthew Woehlke wrote:
>> That would be awesome. In fact I have a 'to do' to suggest exactly this.
>>
>> std::flags might cover that specific use case, but I also want to be
>> able to do things like:
>>
>> enum class foo {
>> ...values...
>> foo(std::string const*); // constructor
>> operator std::string(); // conversion operator
>> };
>>
>> (These sorts of conversions already show up frequently, but right now
>> must be implemented as free functions; the ability to make them members
>> would be great.)
>
> But now that really starts to diverge from Walter's proposal.
Sure. I'm not inclined to believe they're the same proposal. Just
saying, I'd really like the above :-).
> It seems he did leave out member functions/operators on purpose.
> If you want to leverage his work, it seems the best option would be to have
> a non-member form of the cast operator, and also replace the constructor
> with that.
> Something like:
> enum class foo {
> ...values...;
>
> operator std::string(const foo &); // conversion to string operator
> operator foo(const std::string &); // conversion from string operator
> };
>
>> Something else I would really love to see though is using an enumeration
>> as an underlying ("base") type of an enumeration, e.g.:
>>
>> enum class A { a1, a2, ... };
>> enum class B : A { b1, b2, ... };
>>
>> B bb = B::a1; // legal; a1, etc. are in scope of B, inherited from A
>
> But would then be implicit conversions from A allowed?
> B bb = A::a1;
> I would suggest not, because this behavior would need to be a special case.
Heh. I had one originally, and decided to remove it because I'm not sure
of the answer :-). Intuitively I would say "yes", because if all values
of A are also values of B, it makes sense to allow promotion from A to
B, unless such has been explicitly denied.
On the other hand though, it's opposite what implicit type conversions
are allowed for class pointers / references. But maybe it would be more
like numeric promotions, e.g. A -> B is sort of like char -> int.
> Also, what would be the underlying_type_t of B? Would it be A or int?
>
> If it could be A, that could be surprising for a lot of code. It would also
> not play well with Thiago Macieira's idea of multiple inheritance.
>
> At the same type, it would be interesting to have type_traits to query the
> hierarchy of such enums.
>
> How to implement that then? Specialize std::is_base_of?
Probably 'int', a) for the reasons you give above, and b) because I do
think multiple inheritance should be allowed. And I would further agree
that obtaining type 'A' from type 'B' should use the same mechanism as
for "true" classes (which among other things would imply that
is_base_of(A, B) => true).
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Wed, 19 Mar 2014 16:33:42 -0700 (PDT)
Raw View
------=_Part_56_2736425.1395272022717
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 19, 2014 8:02:47 PM UTC-3, Matthew Woehlke wrote:
>
> (I'm leaving the entirety of Matheus text as something appears to have
> eaten that message...)
>
>
It also ate yours. Got them on my email but they don't show up on google
groups web interface.
>
> Heh. I had one originally, and decided to remove it because I'm not sure
> of the answer :-). Intuitively I would say "yes", because if all values
> of A are also values of B, it makes sense to allow promotion from A to
> B, unless such has been explicitly denied.
>
>
It's also kind of the opposite behavior of an enum class deriving from int
though,
where implicit conversions both ways are disallowed.
>
> Probably 'int', a) for the reasons you give above, and b) because I do
> think multiple inheritance should be allowed. And I would further agree
> that obtaining type 'A' from type 'B' should use the same mechanism as
> for "true" classes (which among other things would imply that
> is_base_of(A, B) => true).
>
>
I think making enums full on class-like has been discussed before, but I
can't
find where / which thread it was discussed on.
But as far as I remember, it came out unfavorably.
I am in favor of allowing literal types as enum underlying types, and if
you allow
full on enum classes like that, then using a literal class type as
underlying type could get really hairy.
On the other hand, IMHO making enum classes have similar semantics to
opaque typedefs seems a lot simpler
and fits better, because as they stand right now, they are a lot like an
opaque typedef, but unfortunately support just fundamental integers.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_56_2736425.1395272022717
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 19, 2014 8:02:47 PM UTC-3, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">(I'm leaving the en=
tirety of Matheus text as something appears to have=20
<br>eaten that message...)
<br>
<br></blockquote><div><br>It also ate yours. Got them on my email but they =
don't show up on google groups web interface.<br> </div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><br>Heh. I had one originally, and decided t=
o remove it because I'm not sure=20
<br>of the answer :-). Intuitively I would say "yes", because if all values=
=20
<br>of A are also values of B, it makes sense to allow promotion from A to=
=20
<br>B, unless such has been explicitly denied.
<br>
<br></blockquote><div><br>It's also kind of the opposite behavior of an enu=
m class deriving from int though,<br>where implicit conversions both ways a=
re disallowed.<br> </div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Probably 'int', a) for the reasons you give above, and b) because I do=
=20
<br>think multiple inheritance should be allowed. And I would further agree=
=20
<br>that obtaining type 'A' from type 'B' should use the same mechanism as=
=20
<br>for "true" classes (which among other things would imply that=20
<br>is_base_of(A, B) =3D> true).
<br>
<br></blockquote><div><br>I think making enums full on class-like has been =
discussed before, but I can't<br>find where / which thread it was discussed=
on.<br>But as far as I remember, it came out unfavorably.<br><br>I am in f=
avor of allowing literal types as enum underlying types, and if you allow<b=
r>full on enum classes like that, then using a literal class type as underl=
ying type could get really hairy.<br><br>On the other hand, IMHO making enu=
m classes have similar semantics to opaque typedefs seems a lot simpler<br>=
and fits better, because as they stand right now, they are a lot like an op=
aque typedef, but unfortunately support just fundamental integers.<br></div=
></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_56_2736425.1395272022717--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 20 Mar 2014 12:12:02 -0400
Raw View
On 2014-03-19 19:33, Matheus Izvekov wrote:
> On Wednesday, March 19, 2014 8:02:47 PM UTC-3, Matthew Woehlke wrote:
>> Heh. I had one originally, and decided to remove it because I'm not sure
>> of the answer :-). Intuitively I would say "yes", because if all values
>> of A are also values of B, it makes sense to allow promotion from A to
>> B, unless such has been explicitly denied.
>
> It's also kind of the opposite behavior of an enum class deriving from int
> though, where implicit conversions both ways are disallowed.
True, but an enum is a *restricted* subclass of e.g. int. Given the
previous example:
enum class A : int { ... };
enum class B : A { ... };
....the idea is that all possible values of A are possible values of B.
But clearly not all possible values of int are possible values of A. So
obviously promotion from int to A does not make sense, but promotion
from A to B could make sense. (Similarly, *de*motion for B to A probably
does not make sense and would be disallowed.)
I think the question is, do we write the rules to make the most sense
when considered in isolation, or when considered against "similar"
implicit conversion rules for other types? Or do we take the cop-out and
just disallow all implicit conversions?
My own inclination is to the first, but it's not a strong inclination.
> On the other hand, IMHO making enum classes have similar semantics to
> opaque typedefs seems a lot simpler
> and fits better, because as they stand right now, they are a lot like an
> opaque typedef, but unfortunately support just fundamental integers.
Here maybe is a way to look at it... an enum class is an opaque typedef
with an underlying integer type (say, will std::underlying_type work on
an opaque typedef?), which:
- Has a convenient syntax for providing a list of static members which
are constexpr values of the type initialized from a value of the base type.
- May inherit from one or more enumerations, such that the values of the
base enumerations are accessible as values of the derived enumeration,
having the derived type when references via the same. (Except when
deriving 'private'; see next point.)
- Has reversed order of permissible implicit conversion (i.e. a Base may
convert to a Derived, but not vice versa) versus an "ordinary" opaque
typedef. Probably given similar rules, e.g. 'protected' prevents
implicit conversion, 'private' also hides values of base enum.
....and ideally allow 'member functions' (including constructors and
conversion operators) for opaque typedefs (not just enum class's) as well.
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Wed, 19 Mar 2014 15:14:00 -0700 (PDT)
Raw View
------=_Part_62_5262444.1395267240238
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 19, 2014 2:48:31 PM UTC-3, Matthew Woehlke wrote:
>
>
> That would be awesome. In fact I have a 'to do' to suggest exactly this.
>
> std::flags might cover that specific use case, but I also want to be
> able to do things like:
>
> enum class foo {
> ...values...
> foo(std::string const*); // constructor
> operator std::string(); // conversion operator
> };
>
> (These sorts of conversions already show up frequently, but right now
> must be implemented as free functions; the ability to make them members
> would be great.)
>
>
>
But now that really starts to diverge from Walter's proposal.
It seems he did leave out member functions/operators on purpose.
If you want to leverage his work, it seems the best option would be to have
a non-member form of the cast operator, and also replace the constructor
with that.
Something like:
enum class foo {
...values...;
operator std::string(const foo &); // conversion to string operator
operator foo(const std::string &); // conversion from string operator
};
Something else I would really love to see though is using an enumeration
> as an underlying ("base") type of an enumeration, e.g.:
>
> enum class A { a1, a2, ... };
> enum class B : A { b1, b2, ... };
>
> B bb = B::a1; // legal; a1, etc. are in scope of B, inherited from A
>
>
But would then be implicit conversions from A allowed?
B bb = A::a1;
I would suggest not, because this behavior would need to be a special case.
Also, what would be the underlying_type_t of B? Would it be A or int?
If it could be A, that could be surprising for a lot of code. It would also
not play well with Thiago Macieira's idea of multiple inheritance.
At the same type, it would be interesting to have type_traits to query the
hierarchy of such enums.
How to implement that then? Specialize std::is_base_of?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_62_5262444.1395267240238
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 19, 2014 2:48:31 PM UTC-3, Matthew Woe=
hlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>
That would be awesome. In fact I have a 'to do' to suggest exactly this.
<br>
<br>std::flags might cover that specific use case, but I also want to be=20
<br>able to do things like:
<br>
<br> enum class foo {
<br> ...values...
<br> foo(std::string const*); // constructor
<br> operator std::string(); // conversion operator
<br> };
<br>
<br>(These sorts of conversions already show up frequently, but right now=
=20
<br>must be implemented as free functions; the ability to make them members=
=20
<br>would be great.)
<br>
<br>
<br></blockquote><div> <br>But now that really starts to diverge from =
Walter's proposal.<br>It seems he did leave out member functions/operators =
on purpose.<br>If you want to leverage his work, it seems the best option w=
ould be to have<br>a non-member form of the cast operator, and also replace=
the constructor with that.<br>Something like:<br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> foo </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">values</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">...;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">string=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> foo </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// conversion to string operator</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"></span><br><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify"> &=
nbsp; operator</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> foo</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy"></span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> std::string </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// conversion from string op=
erator</span><span style=3D"color: #000;" class=3D"styled-by-prettify"></sp=
an></code><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">Something else I would really love to see though is using an enum=
eration=20
<br>as an underlying ("base") type of an enumeration, e.g.:
<br>
<br> enum class A { a1, a2, ... };
<br> enum class B : A { b1, b2, ... };
<br>
<br> B bb =3D B::a1; // legal; a1, etc. are in scope of B, inhe=
rited from A
<br>
<br></blockquote><div><br>But would then be implicit conversions from A all=
owed?<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #606;" class=3D"styled-by-prettify">B b=
b =3D A::a1;</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"></span></div></code></div>I would suggest not, because this behavior woul=
d need to be a special case.<br><br>Also, what would be the underlying_type=
_t of B? Would it be A or int?<br><br>If it could be A, that could be surpr=
ising for a lot of code. It would also not play well with Thiago Macieira's=
idea of multiple inheritance.<br><br>At the same type, it would be interes=
ting to have type_traits to query the hierarchy of such enums.<br><br>How t=
o implement that then? Specialize std::is_base_of?<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_62_5262444.1395267240238--
.