Topic: enum class foo : bool {}
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 30 Nov 2016 10:45:00 +0200
Raw View
The trick of declaring type-safe integral types using `enum class
my_int_type : int {}` seems to be quite popular. I propose extending it
to bool:
enum class foo : bool {};
foo x = foo::true; // ok
x = false; // error
foo f1(), f2();
foo y = f1() || f2();
enum class bar : bool {};
enum class baz : bool {};
template <foo a, bar b, baz c> a_template_with_many_options { ... }
using with_my_options = a_template_with_many_options<foo::true,
bar::false, baz::true>;
// more readable than a_template_with_many_options<true,
false, true>;
Such a construct (enum class with no members, derived from bool) would
have logical operators &&/||/! automatically defined, as well as
explicit conversions to regular bool. I think it could help projects
suffering from flag proliferation.
--
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/8414e09f-34eb-870f-83f8-df2f75757c28%40scylladb.com.
.
Author: Dawid Pilarski <dawidpicpp@gmail.com>
Date: Wed, 30 Nov 2016 10:15:04 +0100
Raw View
--089e013d1ae0fb6cb005428123cb
Content-Type: text/plain; charset=UTF-8
I think this is inconsistent with what currently `enum class my_int_type :
int {}' means. It's proper meaning is, that the enum will be of same size
as integer (with no concrete enum labels specified). This has got nothing
to do with inheritance.
In your case specified enum will 'inherit' enums from the boolean type
(true, false).
Also one would have to consider what will :
enum class bar : bool {A,B,C,D}; mean? What is the meaning of true and
false then?
I think better approach is to simply declare:
enum class my_int_type : int {DISABLED, ENABLED}; which is exactly same in
meaning, but does not introduce any strange syntax, that introduces some
inconsistency in standard.
2016-11-30 9:45 GMT+01:00 Avi Kivity <avi@scylladb.com>:
> The trick of declaring type-safe integral types using `enum class
> my_int_type : int {}` seems to be quite popular. I propose extending it to
> bool:
>
>
> enum class foo : bool {};
>
>
> foo x = foo::true; // ok
>
> x = false; // error
>
>
> foo f1(), f2();
>
> foo y = f1() || f2();
>
>
> enum class bar : bool {};
>
> enum class baz : bool {};
>
>
> template <foo a, bar b, baz c> a_template_with_many_options { ... }
>
> using with_my_options = a_template_with_many_options<foo::true,
> bar::false, baz::true>;
> // more readable than a_template_with_many_options<true, false,
> true>;
>
>
> Such a construct (enum class with no members, derived from bool) would
> have logical operators &&/||/! automatically defined, as well as explicit
> conversions to regular bool. I think it could help projects suffering from
> flag proliferation.
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/8414e09f-34eb-870f-83f8-
> df2f75757c28%40scylladb.com.
>
--
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/CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40mail.gmail.com.
--089e013d1ae0fb6cb005428123cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I think this is inconsistent with what currently `enu=
m class my_int_type : int {}' means. It's proper meaning is, that t=
he enum will be of same size as integer (with no concrete enum labels speci=
fied). This has got nothing to do with inheritance.<br><br></div><div>In yo=
ur case specified enum will 'inherit' enums from the boolean type (=
true, false).<br><br></div><div>Also one would have to consider what will :=
<br><br>=C2=A0enum class bar : bool {A,B,C,D}; mean? What is the meaning of=
true and false then?<br><br></div><div>I think better approach is to simpl=
y declare:<br><br>enum class my_int_type : int {DISABLED, ENABLED}; which i=
s exactly same in meaning, but does not introduce any strange syntax, that =
introduces some inconsistency in standard.<br></div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">2016-11-30 9:45 GMT+01:00 Avi Kivi=
ty <span dir=3D"ltr"><<a href=3D"mailto:avi@scylladb.com" target=3D"_bla=
nk">avi@scylladb.com</a>></span>:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The =
trick of declaring type-safe integral types using `enum class my_int_type :=
int {}` seems to be quite popular.=C2=A0 I propose extending it to bool:<b=
r>
<br>
<br>
=C2=A0 =C2=A0enum class foo : bool {};<br>
<br>
<br>
=C2=A0 =C2=A0foo x =3D foo::true;=C2=A0 =C2=A0 // ok<br>
<br>
=C2=A0 =C2=A0x =3D false;=C2=A0 =C2=A0// error<br>
<br>
<br>
=C2=A0 =C2=A0foo f1(), f2();<br>
<br>
=C2=A0 =C2=A0foo y =3D f1() || f2();<br>
<br>
<br>
=C2=A0 =C2=A0enum class bar : bool {};<br>
<br>
=C2=A0 =C2=A0enum class baz : bool {};<br>
<br>
<br>
=C2=A0 =C2=A0template <foo a, bar b, baz c> a_template_with_many_opti=
ons { ... }<br>
<br>
=C2=A0 =C2=A0using with_my_options =3D a_template_with_many_options<f<wb=
r>oo::true, bar::false, baz::true>;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// more readable than a_template_with_man=
y_options<t<wbr>rue, false, true>;<br>
<br>
<br>
Such a construct (enum class with no members, derived from bool) would have=
logical operators &&/||/! automatically defined, as well as explic=
it conversions to regular bool.=C2=A0 I think it could help projects suffer=
ing from flag proliferation.<span class=3D"HOEnZb"><font color=3D"#888888">=
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8414e09f-34eb-870f-83f8-df2f75757c28%=
40scylladb.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/8414e09f-34eb-870f-83f8-<w=
br>df2f75757c28%40scylladb.com</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2D=
Xbpb8JEd1aEpcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiH5dkO70rUn=
fWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40mail.gmail.com</a>.<br />
--089e013d1ae0fb6cb005428123cb--
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 30 Nov 2016 09:18:00 +0000
Raw View
--001a1130cf06758a1f0542812e29
Content-Type: text/plain; charset=UTF-8
I think what you really want is strong typedefs. In which case, I couldn't
agree more. Making a concession to get some odd syntax that restricts the
ability to bool only would be a massive own goal.
--
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/CACGiwhHvNm-BfgYCMY7SvQ2abr9hD9-OhfjrOjkkZntX06A4tg%40mail.gmail.com.
--001a1130cf06758a1f0542812e29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think what you really want is strong typedefs. In which =
case, I couldn't agree more. Making a concession to get some odd syntax=
that restricts the ability to bool only would be a massive own goal.<br><b=
r></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhHvNm-BfgYCMY7SvQ2abr9hD9-Ohfjr=
OjkkZntX06A4tg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhHvNm-BfgYC=
MY7SvQ2abr9hD9-OhfjrOjkkZntX06A4tg%40mail.gmail.com</a>.<br />
--001a1130cf06758a1f0542812e29--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 30 Nov 2016 12:40:59 +0200
Raw View
This is a multi-part message in MIME format.
--------------CEBF1DF280B02E121409E8D6
Content-Type: text/plain; charset=UTF-8; format=flowed
On 11/30/2016 11:15 AM, Dawid Pilarski wrote:
> I think this is inconsistent with what currently `enum class
> my_int_type : int {}' means. It's proper meaning is, that the enum
> will be of same size as integer (with no concrete enum labels
> specified). This has got nothing to do with inheritance.
>
You are missing a special case of enum class : some_type; the one where
no members are specified.
For example there was a proposal to define std::byte as enum class :
uint8_t {}; with the meaning of introducing a new type that has the same
underlying implementation as uint8_t, but does not implicitly convert.
> In your case specified enum will 'inherit' enums from the boolean type
> (true, false).
>
> Also one would have to consider what will :
>
> enum class bar : bool {A,B,C,D}; mean? What is the meaning of true
> and false then?
I am not proposing to change the case where members are specified at
all. Just an enum class, based on bool, without any members.
>
> I think better approach is to simply declare:
>
> enum class my_int_type : int {DISABLED, ENABLED}; which is exactly
> same in meaning, but does not introduce any strange syntax, that
> introduces some inconsistency in standard.
This approach requires the user to define &&, ||, !, and bool conversion
(the last is not allowed, IIUC).
>
> 2016-11-30 9:45 GMT+01:00 Avi Kivity <avi@scylladb.com
> <mailto:avi@scylladb.com>>:
>
> The trick of declaring type-safe integral types using `enum class
> my_int_type : int {}` seems to be quite popular. I propose
> extending it to bool:
>
>
> enum class foo : bool {};
>
>
> foo x = foo::true; // ok
>
> x = false; // error
>
>
> foo f1(), f2();
>
> foo y = f1() || f2();
>
>
> enum class bar : bool {};
>
> enum class baz : bool {};
>
>
> template <foo a, bar b, baz c> a_template_with_many_options { ... }
>
> using with_my_options = a_template_with_many_options<foo::true,
> bar::false, baz::true>;
> // more readable than a_template_with_many_options<true,
> false, true>;
>
>
> Such a construct (enum class with no members, derived from bool)
> would have logical operators &&/||/! automatically defined, as
> well as explicit conversions to regular bool. I think it could
> help projects suffering from flag proliferation.
>
> --
> 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
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8414e09f-34eb-870f-83f8-df2f75757c28%40scylladb.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8414e09f-34eb-870f-83f8-df2f75757c28%40scylladb.com>.
>
>
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/eb39c341-97fd-1337-1707-535ca0cd3875%40scylladb.com.
--------------CEBF1DF280B02E121409E8D6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
On 11/30/2016 11:15 AM, Dawid Pilarski wrote:<br>
<blockquote
cite=3D"mid:CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div>I think this is inconsistent with what currently `enum
class my_int_type : int {}' means. It's proper meaning is,
that the enum will be of same size as integer (with no
concrete enum labels specified). This has got nothing to do
with inheritance.<br>
<br>
</div>
</div>
</blockquote>
<br>
<p>You are missing a special case of enum class : some_type; the one
where no members are specified.</p>
<p><br>
</p>
<p>For example there was a proposal to define std::byte as enum
class : uint8_t {}; with the meaning of introducing a new type
that has the same underlying implementation as uint8_t, but does
not implicitly convert.<br>
</p>
<br>
<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div>In your case specified enum will 'inherit' enums from the
boolean type (true, false).<br>
<br>
</div>
<div>Also one would have to consider what will :<br>
<br>
=C2=A0enum class bar : bool {A,B,C,D}; mean? What is the meaning =
of
true and false then?<br>
</div>
</div>
</blockquote>
<br>
I am not proposing to change the case where members are specified at
all.=C2=A0 Just an enum class, based on bool, without any members.<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>I think better approach is to simply declare:<br>
<br>
enum class my_int_type : int {DISABLED, ENABLED}; which is
exactly same in meaning, but does not introduce any strange
syntax, that introduces some inconsistency in standard.<br>
</div>
</div>
</blockquote>
<br>
This approach requires the user to define &&, ||, !, and
bool conversion (the last is not allowed, IIUC).<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ@mail.gmail.=
com"
type=3D"cite">
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">2016-11-30 9:45 GMT+01:00 Avi Kivity <sp=
an
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scylla=
db.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">The trick
of declaring type-safe integral types using `enum class
my_int_type : int {}` seems to be quite popular.=C2=A0 I propos=
e
extending it to bool:<br>
<br>
<br>
=C2=A0 =C2=A0enum class foo : bool {};<br>
<br>
<br>
=C2=A0 =C2=A0foo x =3D foo::true;=C2=A0 =C2=A0 // ok<br>
<br>
=C2=A0 =C2=A0x =3D false;=C2=A0 =C2=A0// error<br>
<br>
<br>
=C2=A0 =C2=A0foo f1(), f2();<br>
<br>
=C2=A0 =C2=A0foo y =3D f1() || f2();<br>
<br>
<br>
=C2=A0 =C2=A0enum class bar : bool {};<br>
<br>
=C2=A0 =C2=A0enum class baz : bool {};<br>
<br>
<br>
=C2=A0 =C2=A0template <foo a, bar b, baz c>
a_template_with_many_options { ... }<br>
<br>
=C2=A0 =C2=A0using with_my_options =3D a_template_with_many_opt=
ions<f<wbr>oo::true,
bar::false, baz::true>;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// more readable than
a_template_with_many_options<t<wbr>rue, false, true>;<br>
<br>
<br>
Such a construct (enum class with no members, derived from
bool) would have logical operators &&/||/!
automatically defined, as well as explicit conversions to
regular bool.=C2=A0 I think it could help projects suffering fr=
om
flag proliferation.<span class=3D"HOEnZb"><font
color=3D"#888888"><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 moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isoc<wbr>pp.o=
rg</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8414e0=
9f-34eb-870f-83f8-df2f75757c28%40scylladb.com"
rel=3D"noreferrer" target=3D"_blank">https://groups.googl=
e.com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/8414e09f-34eb-870f-83f8-=
<wbr>df2f75757c28%40scylladb.com</a>.<br>
</font></span></blockquote>
</div>
<br>
</div>
-- <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 moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZ=
iH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/CAOkZZiH5dkO70rUnfWub7tJq7uTEpn8bVR2DXbpb8JEd1aEpcQ%40m=
ail.gmail.com</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/eb39c341-97fd-1337-1707-535ca0cd3875%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/eb39c341-97fd-1337-1707-535ca0cd38=
75%40scylladb.com</a>.<br />
--------------CEBF1DF280B02E121409E8D6--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 30 Nov 2016 12:41:54 +0200
Raw View
On 11/30/2016 11:18 AM, D. B. wrote:
> I think what you really want is strong typedefs. In which case, I
> couldn't agree more. Making a concession to get some odd syntax that
> restricts the ability to bool only would be a massive own goal.
>
We already have strong typedefs, their syntax is "enum class new_type :
old_type {};"
--
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/b58ddd77-6223-625e-9766-1fd073a83ad1%40scylladb.com.
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 30 Nov 2016 11:00:40 +0000
Raw View
--001a114312ec94c92c0542829dbb
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 30, 2016 at 10:41 AM, Avi Kivity <avi@scylladb.com> wrote:
>
> We already have strong typedefs, their syntax is "enum class new_type :
> old_type {};"
>
>
Um, no? I don't see what you mean. Using enum class seems hopelessly
limited, being constrained only to integral types and requiring named
enumerators (or horrible casts everywhere).
The definition of "strong typedef" that I'm familiar with is about
declaring a new alias to an existing type - which would use the same
representation *but *perform compile-time checking that what's given was
really declared as the strong typedef, not the original type. Thus ensuring
we really mean what we write.
For instance:
using explicit Money = double; // [Initiate syntax bikeshed]
Money g_my_fortune{1'000'000.00};
void debit_my_account(Money const amount)
{
g_my_fortune -= amount;
}
Money const actual_money = 20.00;
debit_my_account(actual_money); // OK
double const some_arbitrary_value = std::numeric_limits<double>::max(); //
oh no! what a terrible mistake!!
debit_my_account(some_arbitrary_value); // phew! compile-time error.
I know we can approximate this pretty well with user-defined literals, but
it might still be nice to see the above variant, assuming it could be done
without too much hassle.
--
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/CACGiwhFZ4k%2Bkihc6cTzZAADLBTsDbBUVpNG_y0opMTbp3TZRyw%40mail.gmail.com.
--001a114312ec94c92c0542829dbb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Nov 30, 2016 at 10:41 AM, Avi Kivity <span dir=3D"ltr"><<a href=3D"m=
ailto:avi@scylladb.com" target=3D"_blank">avi@scylladb.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"g=
mail-"><br></span>
We already have strong typedefs, their syntax is "enum class new_type =
: old_type {};"<span class=3D"gmail-"><br>
<br></span></blockquote><div><br></div><div>Um, no? I don't see what yo=
u mean. Using enum class seems hopelessly limited, being constrained only t=
o integral types and requiring named enumerators (or horrible casts everywh=
ere).<br><br>The definition of "strong typedef" that I'm fami=
liar with is about declaring a new alias to an existing type - which would =
use the same representation <i>but </i>perform compile-time checking that w=
hat's given was really declared as the strong typedef, not the original=
type. Thus ensuring we really mean what we write.<br><br>For instance:<br>=
=C2=A0<br><div style=3D"margin-left:40px">using explicit Money =3D double; =
// [Initiate syntax bikeshed]<br></div><div style=3D"margin-left:40px"><br>=
</div><div style=3D"margin-left:40px">Money g_my_fortune{1'000'000.=
00};<br></div><div style=3D"margin-left:40px"><br>void debit_my_account(Mon=
ey const amount)<br>{<br></div><div style=3D"margin-left:40px">=C2=A0=C2=A0=
=C2=A0 g_my_fortune -=3D amount;<br></div><div style=3D"margin-left:40px">}=
<br><br></div><div style=3D"margin-left:40px">Money const actual_money =3D=
20.00;<br></div><div style=3D"margin-left:40px">debit_my_account(actual_mo=
ney); // OK<br><br>double const some_arbitrary_value =3D std::numeric_limit=
s<double>::max(); // oh no! what a terrible mistake!!<br>debit_my_acc=
ount(some_arbitrary_value); // phew! compile-time error.<br><br></div>I kno=
w we can approximate this pretty well with user-defined literals, but it mi=
ght still be nice to see the above variant, assuming it could be done witho=
ut too much hassle.<br></div></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFZ4k%2Bkihc6cTzZAADLBTsDbBUVpN=
G_y0opMTbp3TZRyw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFZ4k%2Bk=
ihc6cTzZAADLBTsDbBUVpNG_y0opMTbp3TZRyw%40mail.gmail.com</a>.<br />
--001a114312ec94c92c0542829dbb--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 30 Nov 2016 13:13:07 +0200
Raw View
This is a multi-part message in MIME format.
--------------BD3914FB756FBE94CEBC4A8E
Content-Type: text/plain; charset=UTF-8; format=flowed
On 11/30/2016 01:00 PM, D. B. wrote:
> On Wed, Nov 30, 2016 at 10:41 AM, Avi Kivity <avi@scylladb.com
> <mailto:avi@scylladb.com>> wrote:
>
>
> We already have strong typedefs, their syntax is "enum class
> new_type : old_type {};"
>
>
> Um, no? I don't see what you mean. Using enum class seems hopelessly
> limited, being constrained only to integral types and requiring named
> enumerators (or horrible casts everywhere).
>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0298r0.pdf
--
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/66960f97-7b59-3db4-02f5-bce89cc32934%40scylladb.com.
--------------BD3914FB756FBE94CEBC4A8E
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 11/30/2016 01:00 PM, D. B. wrote:<br>
</div>
<blockquote
cite=3D"mid:CACGiwhFZ4k+kihc6cTzZAADLBTsDbBUVpNG_y0opMTbp3TZRyw@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, Nov 30, 2016 at 10:41 AM, Avi
Kivity <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scyl=
ladb.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-"><br=
>
</span>
We already have strong typedefs, their syntax is "enum
class new_type : old_type {};"<span class=3D"gmail-"><br>
<br>
</span></blockquote>
<div><br>
</div>
<div>Um, no? I don't see what you mean. Using enum class
seems hopelessly limited, being constrained only to
integral types and requiring named enumerators (or
horrible casts everywhere).<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2016/p0298r0.pdf">http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2016/p0298r0.pdf</a><br>
<br>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/66960f97-7b59-3db4-02f5-bce89cc32934%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/66960f97-7b59-3db4-02f5-bce89cc329=
34%40scylladb.com</a>.<br />
--------------BD3914FB756FBE94CEBC4A8E--
.
Author: "D. B." <db0451@gmail.com>
Date: Wed, 30 Nov 2016 11:17:33 +0000
Raw View
--001a11c39b22fb4f3d054282d914
Content-Type: text/plain; charset=UTF-8
....thus proving my point. std::byte can be initialised from an integer
literal but otherwise doesn't act like or interact with one, requiring
manual reimplementation of any desired operators. What I'm talking about is
something that is represented by, and acts like, the underlying/referred
type, but simply can't be interchanged with it at call sites, etc.
I really don't see the point of std::byte anyway, but that's an aside.
--
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/CACGiwhEcOVxq%2BkX%2BZR3Z_m0fc4Q%3DeMcTg%3DQ-cxVmTeQiRWdL1g%40mail.gmail.com.
--001a11c39b22fb4f3d054282d914
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>...thus proving my point. std::byte can be initialise=
d from an integer literal but otherwise doesn't act like or interact wi=
th one, requiring manual reimplementation of any desired operators. What I&=
#39;m talking about is something that is represented by, and acts like, the=
underlying/referred type, but simply can't be interchanged with it at =
call sites, etc.<br><br></div>I really don't see the point of std::byte=
anyway, but that's an aside.<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhEcOVxq%2BkX%2BZR3Z_m0fc4Q%3DeM=
cTg%3DQ-cxVmTeQiRWdL1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEc=
OVxq%2BkX%2BZR3Z_m0fc4Q%3DeMcTg%3DQ-cxVmTeQiRWdL1g%40mail.gmail.com</a>.<br=
/>
--001a11c39b22fb4f3d054282d914--
.
Author: Dawid Pilarski <dawidpicpp@gmail.com>
Date: Wed, 30 Nov 2016 12:18:24 +0100
Raw View
--089e013d1ae01d4122054282dd96
Content-Type: text/plain; charset=UTF-8
This is not strong typedef at all. Simply try to do this with any class or
struct. It will fail. This is enum class without labels and not a typedef
at all. It may behave so for some types, though (integer ones).
I do not see any bad sides of implementing std::byte in this way. Still you
are trying to achieve something different.
True, that it will not behave as bool in bool contexts, but strong typedefs
would do this.
enum class newType:int;
without {} braces is just early declaration of the version
enum class newType:int{}
2016-11-30 11:41 GMT+01:00 Avi Kivity <avi@scylladb.com>:
> On 11/30/2016 11:18 AM, D. B. wrote:
>
>> I think what you really want is strong typedefs. In which case, I
>> couldn't agree more. Making a concession to get some odd syntax that
>> restricts the ability to bool only would be a massive own goal.
>>
>>
> We already have strong typedefs, their syntax is "enum class new_type :
> old_type {};"
>
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/b58ddd77-6223-625e-9766-
> 1fd073a83ad1%40scylladb.com.
>
--
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/CAOkZZiGSF7MoT78SaB5Uu%3D44%2BojDsTMP-rQ_FB%2BS%3DJ%2BWvAS%3D-Q%40mail.gmail.com.
--089e013d1ae01d4122054282dd96
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>This is not strong typedef at all. Sim=
ply try to do this with any class or struct. It will fail. This is enum cla=
ss without labels and not a typedef at all. It may behave so for some types=
, though (integer ones).<br></div>I do not see any bad sides of implementin=
g std::byte in this way. Still you are trying to achieve something differen=
t.</div><br></div>True, that it will not behave as bool in bool contexts, b=
ut strong typedefs would do this.<br><br></div>enum class newType:int;<br><=
br> without {} braces is just early declaration of the version <br>enum cla=
ss newType:int{}<div><div><div><br><br></div></div></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-11-30 11:41 GMT+01:00 =
Avi Kivity <span dir=3D"ltr"><<a href=3D"mailto:avi@scylladb.com" target=
=3D"_blank">avi@scylladb.com</a>></span>:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D"">On 11/30/2016 11:18 AM, D. B. wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I think what you really want is strong typedefs. In which case, I couldn=
9;t agree more. Making a concession to get some odd syntax that restricts t=
he ability to bool only would be a massive own goal.<br>
<br>
</blockquote>
<br></span>
We already have strong typedefs, their syntax is "enum class new_type =
: old_type {};"<span class=3D""><br>
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b58ddd77-6223-625e-9766-1fd073a83ad1%=
40scylladb.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/b58ddd77-6223-625e-9766-<w=
br>1fd073a83ad1%40scylladb.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOkZZiGSF7MoT78SaB5Uu%3D44%2BojDsTMP=
-rQ_FB%2BS%3DJ%2BWvAS%3D-Q%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO=
kZZiGSF7MoT78SaB5Uu%3D44%2BojDsTMP-rQ_FB%2BS%3DJ%2BWvAS%3D-Q%40mail.gmail.c=
om</a>.<br />
--089e013d1ae01d4122054282dd96--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 30 Nov 2016 13:33:42 +0200
Raw View
Please re-read my original proposal, I think you're reacting to
something completely different.
--
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/ccb56376-962b-ea9d-718e-710e2fc7300d%40scylladb.com.
.
Author: Dawid Pilarski <dawidpicpp@gmail.com>
Date: Wed, 30 Nov 2016 15:42:54 +0100
Raw View
--001a114697d86a054d054285b83b
Content-Type: text/plain; charset=UTF-8
"We already have strong typedefs, their syntax is "enum class new_type :
old_type {};"
This is not a strong typedef.
Please note, that allowing syntax:
enum class type : int{A,B,C,D};
and not allowing:
enum class typeB : bool{A, B, C, D};
is very inconsistent. Inconsistency grows with total difference with
semantics of such declaration.
Also
enum class typeB : bool; without labels is strong inconsistency in terms of
semantics, because
enum class typeA : int; //here I mean forward declaration of the enum
class. Here I can do forward declaration, because size is known.
enum class typeB : bool; //here I am declaring new type. No possible way of
forward declaration (because this syntax is already used to declare new
type)
mixing forward declaration syntax with declaration of completely new type
for me seems very dangerous.
Using same syntax for different purposes in different context might be
surprising for the programmer, and using same syntax, which semantics
differ for particular type is just overkill.
Indeed strong typedefs are the solution, but strongly typed enums are not
strong typedefs at all as already mentioned.
2016-11-30 12:33 GMT+01:00 Avi Kivity <avi@scylladb.com>:
> Please re-read my original proposal, I think you're reacting to something
> completely different.
>
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/ccb56376-962b-ea9d-718e-
> 710e2fc7300d%40scylladb.com.
>
--
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/CAOkZZiG-HH7X3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27tg%40mail.gmail.com.
--001a114697d86a054d054285b83b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>"We already have strong typedefs, thei=
r syntax is "enum class new_type : old_type {};"<span class=3D"gm=
ail-im"><br><br></span></div><span class=3D"gmail-im">This is not a strong =
typedef.<br><br></span></div><span class=3D"gmail-im">Please note, that all=
owing syntax:<br><br></span></div><span class=3D"gmail-im">enum class type =
: int{A,B,C,D};<br></span><div><span class=3D"gmail-im"><br></span></div><d=
iv><span class=3D"gmail-im">and not allowing:<br><br></span></div><div><spa=
n class=3D"gmail-im">enum class typeB : bool{A, B, C, D};<br><br></span></d=
iv><div><span class=3D"gmail-im">is very inconsistent. Inconsistency grows =
with total difference with semantics of such declaration.<br><br></span></d=
iv><div><span class=3D"gmail-im">Also<br><br></span></div><div><span class=
=3D"gmail-im">enum class typeB : bool; without labels is strong inconsisten=
cy in terms of semantics, because<br><br></span></div><div><span class=3D"g=
mail-im">enum class typeA : int; //here I mean forward declaration of the e=
num class. Here I can do forward declaration, because size is known.<br></s=
pan></div><div><span class=3D"gmail-im">enum class typeB : bool; //here I a=
m declaring new type. No possible way of forward declaration (because this =
syntax is already used to declare new type)<br><br></span></div><div><span =
class=3D"gmail-im">mixing forward declaration syntax with declaration of co=
mpletely new type for me seems very dangerous.<br><br></span></div><div><sp=
an class=3D"gmail-im">Using same syntax for different purposes in different=
context might be surprising for the programmer, and using same syntax, whi=
ch semantics differ for particular type is just overkill.<br></span></div><=
div><span class=3D"gmail-im">Indeed strong typedefs are the solution, but s=
trongly typed enums are not strong typedefs at all as already mentioned.<br=
></span></div><div><div><span class=3D"gmail-im"><br></span></div></div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-11-30 12:=
33 GMT+01:00 Avi Kivity <span dir=3D"ltr"><<a href=3D"mailto:avi@scyllad=
b.com" target=3D"_blank">avi@scylladb.com</a>></span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Please re-read my original proposal, I think you're re=
acting to something completely different.<span class=3D""><br>
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ccb56376-962b-ea9d-718e-710e2fc7300d%=
40scylladb.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.=
com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/ccb56376-962b-ea9d-718e-<w=
br>710e2fc7300d%40scylladb.com</a>.<br>
</blockquote></div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOkZZiG-HH7X3-%2Bb49JEdcKxpRJ666P4xX=
T%2BPCpLHro-Xi27tg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiG-HH7X=
3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27tg%40mail.gmail.com</a>.<br />
--001a114697d86a054d054285b83b--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Nov 2016 07:53:47 -0800 (PST)
Raw View
------=_Part_16410_1307167529.1480521227223
Content-Type: multipart/alternative;
boundary="----=_Part_16411_627264847.1480521227223"
------=_Part_16411_627264847.1480521227223
Content-Type: text/plain; charset=UTF-8
We should not (further) encourage the (ab)use of `enum class` as a
poor-man's strong typedef. By continuing to do so, we effectively dilute
the need for *real* strong typedefs, thus ensuring that we'll never get
them.
--
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/f13b4386-c91e-4737-9cab-7bb971382780%40isocpp.org.
------=_Part_16411_627264847.1480521227223
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">We should not (further) encourage the (ab)use of `enum cla=
ss` as a=20
poor-man's strong typedef. By continuing to do so, we effectively dilut=
e
the need for <i>real</i> strong typedefs, thus ensuring that we'll nev=
er get them.<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f13b4386-c91e-4737-9cab-7bb971382780%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f13b4386-c91e-4737-9cab-7bb971382780=
%40isocpp.org</a>.<br />
------=_Part_16411_627264847.1480521227223--
------=_Part_16410_1307167529.1480521227223--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 30 Nov 2016 14:15:15 -0600
Raw View
--001a11c1590259babe05428a5f83
Content-Type: text/plain; charset=UTF-8
On Wed, Nov 30, 2016 at 8:42 AM, Dawid Pilarski <dawidpicpp@gmail.com>
wrote:
> enum class type : int{A,B,C,D};
>
> and not allowing:
>
> enum class typeB : bool{A, B, C, D};
>
> is very inconsistent.
>
Given that bool only has two values, what values are C & D supposed to
represent?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BP_kvhg0sgYTWHvugALi0LV-zNRfdTn%3DWowv-3Lx%3DTS9g%40mail.gmail.com.
--001a11c1590259babe05428a5f83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Nov 30, 2016 at 8:42 AM, Dawid Pilarski <span dir=3D"ltr"><<a hr=
ef=3D"mailto:dawidpicpp@gmail.com" target=3D"_blank">dawidpicpp@gmail.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"m_778=
9702968222086133gmail-im">enum class type : int{A,B,C,D};<br></span><div><s=
pan class=3D"m_7789702968222086133gmail-im"><br></span></div><div><span cla=
ss=3D"m_7789702968222086133gmail-im">and not allowing:<br><br></span></div>=
<div><span class=3D"m_7789702968222086133gmail-im">enum class typeB : bool{=
A, B, C, D};<br><br></span></div><div><span class=3D"m_7789702968222086133g=
mail-im">is very inconsistent.</span></div></blockquote></div><br>Given tha=
t bool only has two values, what values are C & D supposed to represent=
?<br>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signatur=
e"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" =
Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></d=
iv></div></div>
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP_kvhg0sgYTWHvugALi0LV-zNRfd=
Tn%3DWowv-3Lx%3DTS9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP_=
kvhg0sgYTWHvugALi0LV-zNRfdTn%3DWowv-3Lx%3DTS9g%40mail.gmail.com</a>.<br />
--001a11c1590259babe05428a5f83--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 30 Nov 2016 22:19:50 +0200
Raw View
On 30 November 2016 at 22:15, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> On Wed, Nov 30, 2016 at 8:42 AM, Dawid Pilarski <dawidpicpp@gmail.com>
> wrote:
>>
>> enum class type : int{A,B,C,D};
>>
>> and not allowing:
>>
>> enum class typeB : bool{A, B, C, D};
>>
>> is very inconsistent.
>
>
> Given that bool only has two values, what values are C & D supposed to
> represent?
Well, I can write
enum class typeB : bool{TRUE = true, FALSE=false, ONE=true, ZERO=false};
today, so C is ONE=true and D is ZERO=false. ;)
--
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/CAFk2RUYzcmMcxxV-h7VqzM3Qp06B%2B5OfMqbr7n5KO0DNmEdPVg%40mail.gmail.com.
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sat, 3 Dec 2016 15:02:41 +0200
Raw View
This is a multi-part message in MIME format.
--------------8B3CB443274DCE91CE02A722
Content-Type: text/plain; charset=UTF-8; format=flowed
On 11/30/2016 04:42 PM, Dawid Pilarski wrote:
> "We already have strong typedefs, their syntax is "enum class new_type
> : old_type {};"
>
> This is not a strong typedef.
>
The designers of std::byte seemed to think that it is. It doesn't
implicitly convert to to uint8_t or its friends, and they don't convert
back.
> Please note, that allowing syntax:
>
> enum class type : int{A,B,C,D};
>
> and not allowing:
>
> enum class typeB : bool{A, B, C, D};
>
> is very inconsistent. Inconsistency grows with total difference with
> semantics of such declaration.
>
I did not propose forbidding "enum class : bool { A, B, C, D };". My
proposal made no comment about it, at all.
> Also
>
> enum class typeB : bool; without labels is strong inconsistency in
> terms of semantics, because
>
I also make no comment about "enum class typeB : bool;"
The proposal only mentioned
enum class typeB : bool {};
which does not conflict with anything.
> enum class typeA : int; //here I mean forward declaration of the enum
> class. Here I can do forward declaration, because size is known.
> enum class typeB : bool; //here I am declaring new type. No possible
> way of forward declaration (because this syntax is already used to
> declare new type)
>
> mixing forward declaration syntax with declaration of completely new
> type for me seems very dangerous.
>
> Using same syntax for different purposes in different context might be
> surprising for the programmer, and using same syntax, which semantics
> differ for particular type is just overkill.
> Indeed strong typedefs are the solution, but strongly typed enums are
> not strong typedefs at all as already mentioned.
>
>
> 2016-11-30 12:33 GMT+01:00 Avi Kivity <avi@scylladb.com
> <mailto:avi@scylladb.com>>:
>
> Please re-read my original proposal, I think you're reacting to
> something completely different.
>
>
> --
> 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
> <mailto:std-proposals%2Bunsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ccb56376-962b-ea9d-718e-710e2fc7300d%40scylladb.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ccb56376-962b-ea9d-718e-710e2fc7300d%40scylladb.com>.
>
>
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiG-HH7X3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27tg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZiG-HH7X3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27tg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/a4f475be-86cb-6141-60c8-d7b1fe166307%40scylladb.com.
--------------8B3CB443274DCE91CE02A722
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 11/30/2016 04:42 PM, Dawid Pilarski
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOkZZiG-HH7X3-+b49JEdcKxpRJ666P4xXT+PCpLHro-Xi27tg@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div>
<div>"We already have strong typedefs, their syntax is "enum
class new_type : old_type {};"<span class=3D"gmail-im"><br>
<br>
</span></div>
<span class=3D"gmail-im">This is not a strong typedef.<br>
<br>
</span></div>
</div>
</div>
</blockquote>
<br>
The designers of std::byte seemed to think that it is.=C2=A0 It doesn't
implicitly convert to to uint8_t or its friends, and they don't
convert back.<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiG-HH7X3-+b49JEdcKxpRJ666P4xXT+PCpLHro-Xi27tg@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div><span class=3D"gmail-im">Please note, that allowing syntax:<br=
>
<br>
</span></div>
<span class=3D"gmail-im">enum class type : int{A,B,C,D};<br>
</span>
<div><span class=3D"gmail-im"><br>
</span></div>
<div><span class=3D"gmail-im">and not allowing:<br>
<br>
</span></div>
<div><span class=3D"gmail-im">enum class typeB : bool{A, B, C, D};<=
br>
<br>
</span></div>
<div><span class=3D"gmail-im">is very inconsistent. Inconsistency
grows with total difference with semantics of such
declaration.<br>
<br>
</span></div>
</div>
</blockquote>
<br>
I did not propose forbidding "enum class : bool { A, B, C, D };".=C2=A0
My proposal made no comment about it, at all.<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiG-HH7X3-+b49JEdcKxpRJ666P4xXT+PCpLHro-Xi27tg@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div><span class=3D"gmail-im">Also<br>
<br>
</span></div>
<div><span class=3D"gmail-im">enum class typeB : bool; without
labels is strong inconsistency in terms of semantics,
because<br>
<br>
</span></div>
</div>
</blockquote>
<br>
I also make no comment about "enum class typeB : bool;"<br>
<br>
The proposal only mentioned <br>
<br>
=C2=A0=C2=A0=C2=A0 enum class typeB : bool {};<br>
<br>
which does not conflict with anything.<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiG-HH7X3-+b49JEdcKxpRJ666P4xXT+PCpLHro-Xi27tg@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div><span class=3D"gmail-im">enum class typeA : int; //here I
mean forward declaration of the enum class. Here I can do
forward declaration, because size is known.<br>
</span></div>
<div><span class=3D"gmail-im">enum class typeB : bool; //here I am
declaring new type. No possible way of forward declaration
(because this syntax is already used to declare new type)<br>
<br>
</span></div>
<div><span class=3D"gmail-im">mixing forward declaration syntax
with declaration of completely new type for me seems very
dangerous.<br>
<br>
</span></div>
<div><span class=3D"gmail-im">Using same syntax for different
purposes in different context might be surprising for the
programmer, and using same syntax, which semantics differ
for particular type is just overkill.<br>
</span></div>
<div><span class=3D"gmail-im">Indeed strong typedefs are the
solution, but strongly typed enums are not strong typedefs
at all as already mentioned.<br>
</span></div>
<div>
<div><span class=3D"gmail-im"><br>
</span></div>
</div>
</div>
</blockquote>
<br>
<br>
<br>
<blockquote
cite=3D"mid:CAOkZZiG-HH7X3-+b49JEdcKxpRJ666P4xXT+PCpLHro-Xi27tg@mail.gmail.=
com"
type=3D"cite">
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">2016-11-30 12:33 GMT+01:00 Avi Kivity <s=
pan
dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:avi@scylladb.com" target=3D"_blank">avi@scylla=
db.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Please
re-read my original proposal, I think you're reacting to
something completely different.<span class=3D""><br>
<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 moz-do-not-send=3D"true"
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"
target=3D"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org=
</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">=
std-proposals@isocpp.org</a>.<br>
</span>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ccb563=
76-962b-ea9d-718e-710e2fc7300d%40scylladb.com"
rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/ccb56376-962b-ea9d-718e-<wbr=
>710e2fc7300d%40scylladb.com</a>.<br>
</blockquote>
</div>
<br>
</div>
-- <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 moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOkZZ=
iG-HH7X3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27tg%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter">https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAOkZZiG-HH7X3-%2Bb49JEdcKxpRJ666P4xXT%2BPCpLHro-Xi27=
tg%40mail.gmail.com</a>.<br>
</blockquote>
<p><br>
</p>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a4f475be-86cb-6141-60c8-d7b1fe166307%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/a4f475be-86cb-6141-60c8-d7b1fe1663=
07%40scylladb.com</a>.<br />
--------------8B3CB443274DCE91CE02A722--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 4 Dec 2016 11:20:33 +0200
Raw View
This is a multi-part message in MIME format.
--------------828CC691C56F7953DE9A7A4E
Content-Type: text/plain; charset=UTF-8; format=flowed
Fair enough.
On 11/30/2016 05:53 PM, Nicol Bolas wrote:
> We should not (further) encourage the (ab)use of `enum class` as a
> poor-man's strong typedef. By continuing to do so, we effectively
> dilute the need for /real/ strong typedefs, thus ensuring that we'll
> never get them.
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f13b4386-c91e-4737-9cab-7bb971382780%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f13b4386-c91e-4737-9cab-7bb971382780%40isocpp.org?utm_medium=email&utm_source=footer>.
--
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/2b0567e3-1207-407e-ae59-95eb92ff5d5e%40scylladb.com.
--------------828CC691C56F7953DE9A7A4E
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p>Fair enough.<br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 11/30/2016 05:53 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote
cite=3D"mid:f13b4386-c91e-4737-9cab-7bb971382780@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">We should not (further) encourage the (ab)use of
`enum class` as a poor-man's strong typedef. By continuing to do
so, we effectively dilute the need for <i>real</i> strong
typedefs, thus ensuring that we'll never get them.<br>
</div>
-- <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 moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
To view this discussion on the web visit <a
moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f13b43=
86-c91e-4737-9cab-7bb971382780%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f=
13b4386-c91e-4737-9cab-7bb971382780%40isocpp.org</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2b0567e3-1207-407e-ae59-95eb92ff5d5e%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/2b0567e3-1207-407e-ae59-95eb92ff5d=
5e%40scylladb.com</a>.<br />
--------------828CC691C56F7953DE9A7A4E--
.