------=_Part_586_405492174.1444309415883
Content-Type: multipart/alternative;
 boundary="----=_Part_587_1744065740.1444309415884"

------=_Part_587_1744065740.1444309415884
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 6:24:14 AM UTC-4,
stephan.bergm...@googlemail.com wrote:
>
> For both scoped and unscoped enums, the range of enumeration values in
> general contains values not defined by any of its enumerators.  (As the
> range of enumeration values is the range of the underlying type if the
> underlying type is fixed, or else the range of the smallest bit-field large
> enough to hold all the enumerator values.)  This poses problems in static
> code analysis, where it is unclear whether the programmer intended to use
> an enumeration as just a set of its enumerators, or as the full range of
> enumeration values.
> For example, in
> enum class E { E1, E2 };
> int f(E e) {
>   int n;
>   switch (e) {
>   case E::E1: n = 1; break;
>   case E::E2: n = 2; break;
>   }
>   return n;
> }
> a static analyzer should arguably warn that n may be used uninitialized in
> the return statement.
>

*Very* arguably.

By using an enum, you are by default stating that the enum can *only have
these values*. And enum class's prevent implicit casts, so you'd have to
cast to move something else in there.

For a static analyzer to assume than an enum could assume values other than
its enumerantors is wrong. Now, if it has *proof* that it could, that's one
thing. But it should not assume that this is the expected case.

If you're using an enum class as a bitfield, through operator overloading
and such, you wouldn't be using switch, so that use case is irrelevant.

But if the programmer knows that objects of type E are intended to only
> ever carry values E1 or E2, they would try to silence the analyzer with
> clumsy code like
> int f(E e) {
>   int n;
>   switch (e) {
>   case E::E1: n = 1; break;
>   case E::E2: n = 2; break;
>   default: std::abort(); // cannot happen
>   }
>   return n;
> }
> A better solution could be to introduce an "enum union" construct into the
> language, that would behave exactly like a scoped enumeration, but whose
> enumeration values would be exactly the set of its enumerator values.
> (Converting an integer outside that set to such an enumeration type would
> result in undefined behavior, per the existing wording of
> [expr.static.cast]).
> This looks like too obvious an enhancement that it wouldn't have been
> discussed before, but I failed to find anything relevant.  Any thoughts?
>

Yes. It's unnecessary. The "safety" offered here is of rather dubious
merit. The only way to convert a foreign integer into an enum class is to
use a static_cast. Which means you've already violated the type system.

C++ is not a safe language. Casting is one of the unsafe places in it.

Also `enum union` is syntax we may want to preserve for other, more useful,
things
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0095r0.html>.

--

---
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_587_1744065740.1444309415884
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 8, 2015 at 6:24:14 AM UTC-4, stephan.bergm...@googlema=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
For both scoped and unscoped enums, the range of enumeration values in gene=
ral contains values not defined by any of its enumerators.=C2=A0 (As the ra=
nge of enumeration values is the range of the underlying type if the underl=
ying type is fixed, or else the range of the smallest bit-field large enoug=
h to hold all the enumerator values.)=C2=A0 This poses problems in static c=
ode analysis, where it is unclear whether the programmer intended to use an=
 enumeration as just a set of its enumerators, or as the full range of enum=
eration values.<br>For example, in<br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x;word-wrap:break-word"><code><div><span style=3D"color:#008">enum</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">class</span><sp=
an style=3D"color:#000"> E </span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"> E1</span><span style=3D"color:#660">,</span><span sty=
le=3D"color:#000"> E2 </span><span style=3D"color:#660">};</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#008">int</span><span styl=
e=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">E e</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"=
color:#000"> n</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"><br>=C2=A0 </span><span style=3D"color:#008">switch</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">e</span><span style=3D"color:#660">)</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#00=
0"><br>=C2=A0 </span><span style=3D"color:#008">case</span><span style=3D"c=
olor:#000"> E</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">E1</span><span style=3D"color:#660">:</span><span style=3D"color:#0=
00"> n </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#066">1</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#008">break</=
span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=
=A0 </span><span style=3D"color:#008">case</span><span style=3D"color:#000"=
> E</span><span style=3D"color:#660">::</span><span style=3D"color:#000">E2=
</span><span style=3D"color:#660">:</span><span style=3D"color:#000"> n </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span=
><span style=3D"color:#066">2</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">break</span><span=
 style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span>=
<span style=3D"color:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </=
span><span style=3D"color:#008">return</span><span style=3D"color:#000"> n<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n></div></code></div>a static analyzer should arguably warn that n may be u=
sed uninitialized in the return statement.</div></blockquote><div><br><i>Ve=
ry</i> arguably.<br><br>By using an enum, you are by default stating that t=
he enum can <i>only have these values</i>. And enum class&#39;s prevent imp=
licit casts, so you&#39;d have to cast to move something else in there.<br>=
<br>For a static analyzer to assume than an enum could assume values other =
than its enumerantors is wrong. Now, if it has <i>proof</i> that it could, =
that&#39;s one thing. But it should not assume that this is the expected ca=
se.<br><br>If you&#39;re using an enum class as a bitfield, through operato=
r overloading and such, you wouldn&#39;t be using switch, so that use case =
is irrelevant.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"> But if the programmer knows that objects of type E are inte=
nded to only ever carry values E1 or E2, they would try to silence the anal=
yzer with clumsy code like<br><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-w=
rap:break-word"><code><div><span style=3D"color:#008">int</span><span style=
=3D"color:#000"> f</span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">E e</span><span style=3D"color:#660">)</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#0=
00"><br>=C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"c=
olor:#000"> n</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br>=C2=A0 </span><span style=3D"color:#008">switch</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">e</span><span style=3D"color:#660">)</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000=
"><br>=C2=A0 </span><span style=3D"color:#008">case</span><span style=3D"co=
lor:#000"> E</span><span style=3D"color:#660">::</span><span style=3D"color=
:#000">E1</span><span style=3D"color:#660">:</span><span style=3D"color:#00=
0"> n </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> </span><span style=3D"color:#066">1</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">break</s=
pan><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=
=A0 </span><span style=3D"color:#008">case</span><span style=3D"color:#000"=
> E</span><span style=3D"color:#660">::</span><span style=3D"color:#000">E2=
</span><span style=3D"color:#660">:</span><span style=3D"color:#000"> n </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span=
><span style=3D"color:#066">2</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">break</span><span=
 style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span>=
<span style=3D"color:#008">default</span><span style=3D"color:#660">:</span=
><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</span>=
<span style=3D"color:#000">abort</span><span style=3D"color:#660">();</span=
><span style=3D"color:#000"> </span><span style=3D"color:#800">// cannot ha=
ppen</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"colo=
r:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D=
"color:#008">return</span><span style=3D"color:#000"> n</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></code>=
</div>A better solution could be to introduce an &quot;enum union&quot; con=
struct into the language, that would behave exactly like a scoped enumerati=
on, but whose enumeration values would be exactly the set of its enumerator=
 values.=C2=A0 (Converting an integer outside that set to such an enumerati=
on type would result in undefined behavior, per the existing wording of [ex=
pr.static.cast]).<br>This looks like too obvious an enhancement that it wou=
ldn&#39;t have been discussed before, but I failed to find anything relevan=
t.=C2=A0 Any thoughts?<br></div></blockquote><div><br>Yes. It&#39;s unneces=
sary. The &quot;safety&quot; offered here is of rather dubious merit. The o=
nly way to convert a foreign integer into an enum class is to use a static_=
cast. Which means you&#39;ve already violated the type system.<br><br>C++ i=
s not a safe language. Casting is one of the unsafe places in it.<br><br>Al=
so `enum union` is syntax we may want to preserve for <a href=3D"http://www=
..open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0095r0.html">other, more use=
ful, things</a>.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_587_1744065740.1444309415884--
------=_Part_586_405492174.1444309415883--

.

On 2015-10-08 09:03, Nicol Bolas wrote:
> If you're using an enum class as a bitfield, through operator overloading
> and such, you wouldn't be using switch, so that use case is irrelevant.

....and you ought to be using std::flags<Enum> for that, anyway (if,
y'know, we could actually get std::flags...), as opposed to Enum directly.

--
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/.

.

--001a11403592b8be2f05219914ca
Content-Type: text/plain; charset=UTF-8

Unfortunately enums value-initialize to 0, regardless of whether 0 is one
of the enumeration values.

On Thu, Oct 8, 2015 at 9:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, October 8, 2015 at 6:24:14 AM UTC-4,
> stephan.bergm...@googlemail.com wrote:
>>
>> For both scoped and unscoped enums, the range of enumeration values in
>> general contains values not defined by any of its enumerators.  (As the
>> range of enumeration values is the range of the underlying type if the
>> underlying type is fixed, or else the range of the smallest bit-field large
>> enough to hold all the enumerator values.)  This poses problems in static
>> code analysis, where it is unclear whether the programmer intended to use
>> an enumeration as just a set of its enumerators, or as the full range of
>> enumeration values.
>> For example, in
>> enum class E { E1, E2 };
>> int f(E e) {
>>   int n;
>>   switch (e) {
>>   case E::E1: n = 1; break;
>>   case E::E2: n = 2; break;
>>   }
>>   return n;
>> }
>> a static analyzer should arguably warn that n may be used uninitialized
>> in the return statement.
>>
>
> *Very* arguably.
>
> By using an enum, you are by default stating that the enum can *only have
> these values*. And enum class's prevent implicit casts, so you'd have to
> cast to move something else in there.
>
> For a static analyzer to assume than an enum could assume values other
> than its enumerantors is wrong. Now, if it has *proof* that it could,
> that's one thing. But it should not assume that this is the expected case.
>
> If you're using an enum class as a bitfield, through operator overloading
> and such, you wouldn't be using switch, so that use case is irrelevant.
>
> But if the programmer knows that objects of type E are intended to only
>> ever carry values E1 or E2, they would try to silence the analyzer with
>> clumsy code like
>> int f(E e) {
>>   int n;
>>   switch (e) {
>>   case E::E1: n = 1; break;
>>   case E::E2: n = 2; break;
>>   default: std::abort(); // cannot happen
>>   }
>>   return n;
>> }
>> A better solution could be to introduce an "enum union" construct into
>> the language, that would behave exactly like a scoped enumeration, but
>> whose enumeration values would be exactly the set of its enumerator
>> values.  (Converting an integer outside that set to such an enumeration
>> type would result in undefined behavior, per the existing wording of
>> [expr.static.cast]).
>> This looks like too obvious an enhancement that it wouldn't have been
>> discussed before, but I failed to find anything relevant.  Any thoughts?
>>
>
> Yes. It's unnecessary. The "safety" offered here is of rather dubious
> merit. The only way to convert a foreign integer into an enum class is to
> use a static_cast. Which means you've already violated the type system.
>
> C++ is not a safe language. Casting is one of the unsafe places in it.
>
> Also `enum union` is syntax we may want to preserve for other, more
> useful, things
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0095r0.html>.
>
> --
>
> ---
> 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/.
>

--

---
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/.

--001a11403592b8be2f05219914ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br></div>Unfortunately enums value-initialize to 0, =
regardless of whether 0 is one of the enumeration values.<br></div><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oct 8, 2015 at 9:=
03 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.=
com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D"">On Thursday, October 8, 2015 at 6:=
24:14 AM UTC-4, <a href=3D"mailto:stephan.bergm...@googlemail.com" target=
=3D"_blank">stephan.bergm...@googlemail.com</a> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">For both scoped and unscoped enums, the=
 range of enumeration values in general contains values not defined by any =
of its enumerators.=C2=A0 (As the range of enumeration values is the range =
of the underlying type if the underlying type is fixed, or else the range o=
f the smallest bit-field large enough to hold all the enumerator values.)=
=C2=A0 This poses problems in static code analysis, where it is unclear whe=
ther the programmer intended to use an enumeration as just a set of its enu=
merators, or as the full range of enumeration values.<br>For example, in<br=
><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,1=
87);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><s=
pan style=3D"color:#008">enum</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">class</span><span style=3D"color:#000"> E </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"> E1</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> E2 </span><span st=
yle=3D"color:#660">};</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#008">int</span><span style=3D"color:#000"> f</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">E e</span><span style=3D=
"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D=
"color:#008">int</span><span style=3D"color:#000"> n</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=
=3D"color:#008">switch</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">e</span><span style=3D"c=
olor:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:=
#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"c=
olor:#008">case</span><span style=3D"color:#000"> E</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#000">E1</span><span style=3D"color=
:#660">:</span><span style=3D"color:#000"> n </span><span style=3D"color:#6=
60">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#066"=
>1</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">break</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">=
case</span><span style=3D"color:#000"> E</span><span style=3D"color:#660">:=
:</span><span style=3D"color:#000">E2</span><span style=3D"color:#660">:</s=
pan><span style=3D"color:#000"> n </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#066">2</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#008">break</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">}</span><sp=
an style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">return=
</span><span style=3D"color:#000"> n</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span=
><span style=3D"color:#000"><br></span></div></code></div>a static analyzer=
 should arguably warn that n may be used uninitialized in the return statem=
ent.</div></blockquote></span><div><br><i>Very</i> arguably.<br><br>By usin=
g an enum, you are by default stating that the enum can <i>only have these =
values</i>. And enum class&#39;s prevent implicit casts, so you&#39;d have =
to cast to move something else in there.<br><br>For a static analyzer to as=
sume than an enum could assume values other than its enumerantors is wrong.=
 Now, if it has <i>proof</i> that it could, that&#39;s one thing. But it sh=
ould not assume that this is the expected case.<br><br>If you&#39;re using =
an enum class as a bitfield, through operator overloading and such, you wou=
ldn&#39;t be using switch, so that use case is irrelevant.<br><br></div><sp=
an class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"> But=
 if the programmer knows that objects of type E are intended to only ever c=
arry values E1 or E2, they would try to silence the analyzer with clumsy co=
de like<br><div 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><div><span style=3D"color:#008">int</span><span style=3D"color:#000"> f<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">E e</sp=
an><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> n</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 <=
/span><span style=3D"color:#008">switch</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">e</span=
><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span=
><span style=3D"color:#008">case</span><span style=3D"color:#000"> E</span>=
<span style=3D"color:#660">::</span><span style=3D"color:#000">E1</span><sp=
an style=3D"color:#660">:</span><span style=3D"color:#000"> n </span><span =
style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#066">1</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">break</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span><span styl=
e=3D"color:#008">case</span><span style=3D"color:#000"> E</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">E2</span><span style=3D=
"color:#660">:</span><span style=3D"color:#000"> n </span><span style=3D"co=
lor:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">2</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">break</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:=
#008">default</span><span style=3D"color:#660">:</span><span style=3D"color=
:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"color:=
#000">abort</span><span style=3D"color:#660">();</span><span style=3D"color=
:#000"> </span><span style=3D"color:#800">// cannot happen</span><span styl=
e=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">}</span><span=
 style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">return</=
span><span style=3D"color:#000"> n</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><=
span style=3D"color:#000"><br></span></div></code></div>A better solution c=
ould be to introduce an &quot;enum union&quot; construct into the language,=
 that would behave exactly like a scoped enumeration, but whose enumeration=
 values would be exactly the set of its enumerator values.=C2=A0 (Convertin=
g an integer outside that set to such an enumeration type would result in u=
ndefined behavior, per the existing wording of [expr.static.cast]).<br>This=
 looks like too obvious an enhancement that it wouldn&#39;t have been discu=
ssed before, but I failed to find anything relevant.=C2=A0 Any thoughts?<br=
></div></blockquote></span><div><br>Yes. It&#39;s unnecessary. The &quot;sa=
fety&quot; offered here is of rather dubious merit. The only way to convert=
 a foreign integer into an enum class is to use a static_cast. Which means =
you&#39;ve already violated the type system.<br><br>C++ is not a safe langu=
age. Casting is one of the unsafe places in it.<br><br>Also `enum union` is=
 syntax we may want to preserve for <a href=3D"http://www.open-std.org/JTC1=
/SC22/WG21/docs/papers/2015/p0095r0.html" target=3D"_blank">other, more use=
ful, things</a>.<br></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a11403592b8be2f05219914ca--

.

--94eb2c0961c47b112c05219c27e3
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> By using an enum, you are by default stating that the enum can *only have
> these values*.
>

Unfortunately (or not unfortunately, depending on what you're using the
enum for) that's not true. The enum can have any of the values of the
underlying type in a well-formed program. This is very common when using
enums for flags. If you want a type that really has the restriction you are
talking about, enums don't get you there directly. You need to make your
own type.

On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> For a static analyzer to assume than an enum could assume values other
> than its enumerantors is wrong.
>

No it's not. It can certainly warn you that you *might* have a mistake,
though understand that this would be a noisy warning that has a lot of
false positives. It's perfectly fine for an enum to not be holding one of
the values that is not named.

On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> The only way to convert a foreign integer into an enum class is to use a
> static_cast. Which means you've already violated the type system.
>

That's not a violation of the type system, that's a perfectly well-formed
operation.

--

---
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/.

--94eb2c0961c47b112c05219c27e3
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 T=
hu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div>By using an enum, you are by default statin=
g that the enum can <i>only have these values</i>.</div></blockquote><div><=
br></div><div>Unfortunately (or not unfortunately, depending on what you&#3=
9;re using the enum for) that&#39;s not true. The enum can have any of the =
values of the underlying type in a well-formed program. This is very common=
 when using enums for flags. If you want a type that really has the restric=
tion you are talking about, enums don&#39;t get you there directly. You nee=
d to make your own type.</div><div><br></div><div>On Thu, Oct 8, 2015 at 6:=
03 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@g=
mail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div>For a static analyzer to assume than an enum=
 could assume values other than its enumerantors is wrong.<br></div></block=
quote><div><br></div><div>No it&#39;s not. It can certainly warn you that y=
ou <i>might</i> have a mistake, though understand that this would be a nois=
y warning that has a lot of false positives. It&#39;s perfectly fine for an=
 enum to not be holding one of the values that is not named.</div><div><br>=
</div><div>On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas=C2=A0<span dir=3D"lt=
r">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@g=
mail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>The on=
ly way to convert a foreign integer into an enum class is to use a static_c=
ast. Which means you&#39;ve already violated the type system.<br></div></bl=
ockquote><div><br></div><div>That&#39;s not a violation of the type system,=
 that&#39;s a perfectly well-formed operation.</div></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&quot; 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 />

--94eb2c0961c47b112c05219c27e3--

.

------=_Part_872_1764285315.1444334091580
Content-Type: multipart/alternative;
 boundary="----=_Part_873_1700193651.1444334091580"

------=_Part_873_1700193651.1444334091580
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 2:37:29 PM UTC-4, Matt Calabrese wrote:
>
> On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> By using an enum, you are by default stating that the enum can *only
>> have these values*.
>>
>
> Unfortunately (or not unfortunately, depending on what you're using the
> enum for) that's not true. The enum can have any of the values of the
> underlying type in a well-formed program. This is very common when using
> enums for flags. If you want a type that really has the restriction you are
> talking about, enums don't get you there directly. You need to make your
> own type.
>

C++ lets you get away with all manor of nonsense through casting. However,
"by default", you're not allowed to convert an integer to an enum class.
Just as, "by default", you're not allowed to convert a pointer to one type
into a pointer to an unrelated type. You need to do a cast, and the result
of that cast may or may not be defined (depending on various things).


> On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> For a static analyzer to assume than an enum could assume values other
>> than its enumerantors is wrong.
>>
>
> No it's not. It can certainly warn you that you *might* have a mistake,
> though understand that this would be a noisy warning that has a lot of
> false positives. It's perfectly fine for an enum to not be holding one of
> the values that is not named.
>

In terms of legal C++ code, yes. In terms of *reasonable* C++ code, no.

Compilers shouldn't try to out-guess you. If you use an enum (class) in a
switch, there is no reason for the compiler to assume that you did
something conceptually dubious.

Otherwise, you'll just end up with a bunch of false-positives, which makes
you ignore the warning entirely.


> On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> The only way to convert a foreign integer into an enum class is to use a
>> static_cast. Which means you've already violated the type system.
>>
>
> That's not a violation of the type system, that's a perfectly well-formed
> operation.
>

Casting a pointer to a `void*` is well-defined too, but that doesn't mean
you haven't violated the type system. You've simply done so in a
well-defined manor.

Casting an integer into an enum type is not something you ought to do. It's
something you can do, with specific results. But you're still deliberately
breaking the type system.

--

---
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_873_1700193651.1444334091580
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 8, 2015 at 2:37:29 PM UTC-4, Matt Calabrese wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
e2F-TtDODAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>By using an=
 enum, you are by default stating that the enum can <i>only have these valu=
es</i>.</div></blockquote><div><br></div><div>Unfortunately (or not unfortu=
nately, depending on what you&#39;re using the enum for) that&#39;s not tru=
e. The enum can have any of the values of the underlying type in a well-for=
med program. This is very common when using enums for flags. If you want a =
type that really has the restriction you are talking about, enums don&#39;t=
 get you there directly. You need to make your own type.</div></div></div><=
/div></blockquote><div><br>C++ lets you get away with all manor of nonsense=
 through casting. However, &quot;by default&quot;, you&#39;re not allowed t=
o convert an integer to an enum class. Just as, &quot;by default&quot;, you=
&#39;re not allowed to convert a pointer to one type into a pointer to an u=
nrelated type. You need to do a cast, and the result of that cast may or ma=
y not be defined (depending on various things).<br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div></div><div>On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas=C2=A0<sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"e2F-TtDODAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">jmck...@gmail.com</a>&gt;</span>=C2=A0<wbr>wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div>For a static analyzer to assume than an enum could assu=
me values other than its enumerantors is wrong.<br></div></blockquote><div>=
<br></div><div>No it&#39;s not. It can certainly warn you that you <i>might=
</i> have a mistake, though understand that this would be a noisy warning t=
hat has a lot of false positives. It&#39;s perfectly fine for an enum to no=
t be holding one of the values that is not named.</div></div></div></div></=
blockquote><div><br>In terms of legal C++ code, yes. In terms of <i>reasona=
ble</i> C++ code, no.<br><br>Compilers shouldn&#39;t try to out-guess you. =
If you use an enum (class) in a switch, there is no reason for the compiler=
 to assume that you did something conceptually dubious.<br><br>Otherwise, y=
ou&#39;ll just end up with a bunch of false-positives, which makes you igno=
re the warning entirely.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=
On Thu, Oct 8, 2015 at 6:03 AM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"e2F-TtDODAAJ=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return =
true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@g=
mail.com</a>&gt;</span>=C2=A0<wbr>wrote:=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>T=
he only way to convert a foreign integer into an enum class is to use a sta=
tic_cast. Which means you&#39;ve already violated the type system.<br></div=
></blockquote><div><br></div><div>That&#39;s not a violation of the type sy=
stem, that&#39;s a perfectly well-formed operation.</div></div></div></div>=
</blockquote><div><br>Casting a pointer to a `void*` is well-defined too, b=
ut that doesn&#39;t mean you haven&#39;t violated the type system. You&#39;=
ve simply done so in a well-defined manor.<br><br>Casting an integer into a=
n enum type is not something you ought to do. It&#39;s something you can do=
, with specific results. But you&#39;re still deliberately breaking the typ=
e system.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_873_1700193651.1444334091580--
------=_Part_872_1764285315.1444334091580--

.

--001a11c2feb26a632105219d8388
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> C++ lets you get away with all manor of nonsense through casting. However,
> "by default", you're not allowed to convert an integer to an enum class.
> Just as, "by default", you're not allowed to convert a pointer to one type
> into a pointer to an unrelated type. You need to do a cast, and the result
> of that cast may or may not be defined (depending on various things).
>

Converting between unrelated pointer types is very different -- you get
undefined behavior if the alignments aren't compatible. Converting between
an enum and its underlying type, on the other hand, is not undefined
behavior. It's perfectly well-defined and not an error, and also frequently
done in practice. Just because a conversion requires an explicit cast does
not mean it is undefined behavior, and your notion of "by default" is
meaningless with respect to the standard. A programmer using an enum with
values other than the explicitly enumerated constants is perfectly valid in
C++.

On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> In terms of legal C++ code, yes. In terms of *reasonable* C++ code, no.
>

The C++ standard doesn't care what an individual programmer deems
"reasonable." It's perfectly acceptable and well-defined. Further,
representing flags with enums is reasonable to many developers, is
perfectly fine with respect to the standard, and is frequently done in
practice. If you want something that doesn't allow this, then an enum is
not the tool that you want, which is why the OP suggests a new facility.

On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Casting a pointer to a `void*` is well-defined too, but that doesn't mean
> you haven't violated the type system. You've simply done so in a
> well-defined manor.
>

A cast being explicit isn't a "violation of the type system." Any explicit
constructor call taking 1 argument requires an explicit cast, too (either
an explicit constructor call or a static_cast). These aren't "violations of
the type system," they are just explicit conversions. Those aren't
"violations of the type system" just like casting back and forth between an
enum and its underlying value is not. If you personally don't like having
enums that hold other values, then that's fine, by convention you can
choose not to do it, but understand that there is nothing logically
incorrect about it and it is not "violating the type system" as you claim.
A compiler cannot and will not assume that your enum only holds the
explicitly enumerated values -- that's just not what an enum is in C++
whether you personally feel that is "unreasonable" or not. It can always
choose to warn on such cases, but that will necessarily be a noisy warning.

--

---
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/.

--001a11c2feb26a632105219d8388
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 T=
hu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div>C++ lets you get away with all manor of no=
nsense through casting. However, &quot;by default&quot;, you&#39;re not all=
owed to convert an integer to an enum class. Just as, &quot;by default&quot=
;, you&#39;re not allowed to convert a pointer to one type into a pointer t=
o an unrelated type. You need to do a cast, and the result of that cast may=
 or may not be defined (depending on various things).<br></div></blockquote=
><div><br></div><div>Converting between unrelated pointer types is very dif=
ferent -- you get undefined behavior if the alignments aren&#39;t compatibl=
e. Converting between an enum and its underlying type, on the other hand, i=
s not undefined behavior. It&#39;s perfectly well-defined and not an error,=
 and also frequently done in practice. Just because a conversion requires a=
n explicit cast does not mean it is undefined behavior, and your notion of =
&quot;by default&quot; is meaningless with respect to the standard. A progr=
ammer using an enum with values other than the explicitly enumerated consta=
nts is perfectly valid in C++.</div><div><br></div><div>On Thu, Oct 8, 2015=
 at 12:54 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmck=
esson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0=
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div>In terms of legal C++ code, yes. In terms=
 of <i>reasonable</i> C++ code, no.<br></div></blockquote><div><br></div><d=
iv>The C++ standard doesn&#39;t care what an individual programmer deems &q=
uot;reasonable.&quot; It&#39;s perfectly acceptable and well-defined. Furth=
er, representing flags with enums is reasonable to many developers, is perf=
ectly fine with respect to the standard, and is frequently done in practice=
.. If you want something that doesn&#39;t allow this, then an enum is not th=
e tool that you want, which is why the OP suggests a new facility.</div><di=
v>=C2=A0</div><div>On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas=C2=A0<span =
dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jm=
ckesson@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Cas=
ting a pointer to a `void*` is well-defined too, but that doesn&#39;t mean =
you haven&#39;t violated the type system. You&#39;ve simply done so in a we=
ll-defined manor.<br></div></blockquote><div><br></div><div>A cast being ex=
plicit isn&#39;t a &quot;violation of the type system.&quot; Any explicit c=
onstructor call taking 1 argument requires an explicit cast, too (either an=
 explicit constructor call or a static_cast). These aren&#39;t &quot;violat=
ions of the type system,&quot; they are just explicit conversions. Those ar=
en&#39;t &quot;violations of the type system&quot; just like casting back a=
nd forth between an enum and its underlying value is not. If you personally=
 don&#39;t like having enums that hold other values, then that&#39;s fine, =
by convention you can choose not to do it, but understand that there is not=
hing logically incorrect about it and it is not &quot;violating the type sy=
stem&quot; as you claim. A compiler cannot and will not assume that your en=
um only holds the explicitly enumerated values -- that&#39;s just not what =
an enum is in C++ whether you personally feel that is &quot;unreasonable&qu=
ot; or not. It can always choose to warn on such cases, but that will neces=
sarily be a noisy warning.=C2=A0</div><div>=C2=A0<br></div></div></div></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a11c2feb26a632105219d8388--

.

--001a11403322e83fed05219d9d41
Content-Type: text/plain; charset=UTF-8

Whether it is valid or not, I would just describe it as a "bad smell" or
"questionable" if I see ints being stuffed into enums. ie during a code
review I would be asking for an explanation.  |'ing for flags is
acceptable, but there are somewhat nice ways to handle it (ie explicitly
write | operators - a nicer way to deal with flags would be lovely.)

On Thu, Oct 8, 2015 at 4:14 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> C++ lets you get away with all manor of nonsense through casting.
>> However, "by default", you're not allowed to convert an integer to an enum
>> class. Just as, "by default", you're not allowed to convert a pointer to
>> one type into a pointer to an unrelated type. You need to do a cast, and
>> the result of that cast may or may not be defined (depending on various
>> things).
>>
>
> Converting between unrelated pointer types is very different -- you get
> undefined behavior if the alignments aren't compatible. Converting between
> an enum and its underlying type, on the other hand, is not undefined
> behavior. It's perfectly well-defined and not an error, and also frequently
> done in practice. Just because a conversion requires an explicit cast does
> not mean it is undefined behavior, and your notion of "by default" is
> meaningless with respect to the standard. A programmer using an enum with
> values other than the explicitly enumerated constants is perfectly valid in
> C++.
>
> On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> In terms of legal C++ code, yes. In terms of *reasonable* C++ code, no.
>>
>
> The C++ standard doesn't care what an individual programmer deems
> "reasonable." It's perfectly acceptable and well-defined. Further,
> representing flags with enums is reasonable to many developers, is
> perfectly fine with respect to the standard, and is frequently done in
> practice. If you want something that doesn't allow this, then an enum is
> not the tool that you want, which is why the OP suggests a new facility.
>
> On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> Casting a pointer to a `void*` is well-defined too, but that doesn't mean
>> you haven't violated the type system. You've simply done so in a
>> well-defined manor.
>>
>
> A cast being explicit isn't a "violation of the type system." Any explicit
> constructor call taking 1 argument requires an explicit cast, too (either
> an explicit constructor call or a static_cast). These aren't "violations of
> the type system," they are just explicit conversions. Those aren't
> "violations of the type system" just like casting back and forth between an
> enum and its underlying value is not. If you personally don't like having
> enums that hold other values, then that's fine, by convention you can
> choose not to do it, but understand that there is nothing logically
> incorrect about it and it is not "violating the type system" as you claim.
> A compiler cannot and will not assume that your enum only holds the
> explicitly enumerated values -- that's just not what an enum is in C++
> whether you personally feel that is "unreasonable" or not. It can always
> choose to warn on such cases, but that will necessarily be a noisy warning.
>
>
> --
>
> ---
> 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/.
>

--

---
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/.

--001a11403322e83fed05219d9d41
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Whether it is valid or not, I would just describe it as a =
&quot;bad smell&quot; or &quot;questionable&quot; if I see ints being stuff=
ed into enums. ie during a code review I would be asking for an explanation=
..=C2=A0 |&#39;ing for flags is acceptable, but there are somewhat nice ways=
 to handle it (ie explicitly write | operators - a nicer way to deal with f=
lags would be lovely.)<br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Oct 8, 2015 at 4:14 PM, &#39;Matt Calabrese&#39; v=
ia ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On Thu, =
Oct 8, 2015 at 12:54 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div>C++ lets you get away with all manor of nonsen=
se through casting. However, &quot;by default&quot;, you&#39;re not allowed=
 to convert an integer to an enum class. Just as, &quot;by default&quot;, y=
ou&#39;re not allowed to convert a pointer to one type into a pointer to an=
 unrelated type. You need to do a cast, and the result of that cast may or =
may not be defined (depending on various things).<br></div></blockquote><di=
v><br></div></span><div>Converting between unrelated pointer types is very =
different -- you get undefined behavior if the alignments aren&#39;t compat=
ible. Converting between an enum and its underlying type, on the other hand=
, is not undefined behavior. It&#39;s perfectly well-defined and not an err=
or, and also frequently done in practice. Just because a conversion require=
s an explicit cast does not mean it is undefined behavior, and your notion =
of &quot;by default&quot; is meaningless with respect to the standard. A pr=
ogrammer using an enum with values other than the explicitly enumerated con=
stants is perfectly valid in C++.</div><span class=3D""><div><br></div><div=
>On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com<=
/a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div>In terms of legal C++=
 code, yes. In terms of <i>reasonable</i> C++ code, no.<br></div></blockquo=
te><div><br></div></span><div>The C++ standard doesn&#39;t care what an ind=
ividual programmer deems &quot;reasonable.&quot; It&#39;s perfectly accepta=
ble and well-defined. Further, representing flags with enums is reasonable =
to many developers, is perfectly fine with respect to the standard, and is =
frequently done in practice. If you want something that doesn&#39;t allow t=
his, then an enum is not the tool that you want, which is why the OP sugges=
ts a new facility.</div><span class=3D""><div>=C2=A0</div><div>On Thu, Oct =
8, 2015 at 12:54 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span=
>=C2=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex"><div>Casting a pointer to a `void*` is =
well-defined too, but that doesn&#39;t mean you haven&#39;t violated the ty=
pe system. You&#39;ve simply done so in a well-defined manor.<br></div></bl=
ockquote><div><br></div></span><div>A cast being explicit isn&#39;t a &quot=
;violation of the type system.&quot; Any explicit constructor call taking 1=
 argument requires an explicit cast, too (either an explicit constructor ca=
ll or a static_cast). These aren&#39;t &quot;violations of the type system,=
&quot; they are just explicit conversions. Those aren&#39;t &quot;violation=
s of the type system&quot; just like casting back and forth between an enum=
 and its underlying value is not. If you personally don&#39;t like having e=
nums that hold other values, then that&#39;s fine, by convention you can ch=
oose not to do it, but understand that there is nothing logically incorrect=
 about it and it is not &quot;violating the type system&quot; as you claim.=
 A compiler cannot and will not assume that your enum only holds the explic=
itly enumerated values -- that&#39;s just not what an enum is in C++ whethe=
r you personally feel that is &quot;unreasonable&quot; or not. It can alway=
s choose to warn on such cases, but that will necessarily be a noisy warnin=
g.=C2=A0</div><div>=C2=A0<br></div></div></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a11403322e83fed05219d9d41--

.

--001a11c29966b6cfe005219db957
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2015 at 1:22 PM, Tony V E <tvaneerd@gmail.com> wrote:

> Whether it is valid or not, I would just describe it as a "bad smell" or
> "questionable" if I see ints being stuffed into enums. ie during a code
> review I would be asking for an explanation.
>

Definitely, but that's very different from it being incorrect. A compiler
cannot assume anything here, which is why a different facility is not
unreasonable.

On Thu, Oct 8, 2015 at 1:22 PM, Tony V E <tvaneerd@gmail.com> wrote:

> |'ing for flags is acceptable, but there are somewhat nice ways to handle
> it (ie explicitly write | operators - a nicer way to deal with flags would
> be lovely.)
>

If you explicitly write an | operator with an enum class when representing
flags, you're likely going to be doing a cast internal to the definition of
the |. You get the underlying value, perform the operation, and cast it
back.

--

---
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/.

--001a11c29966b6cfe005219db957
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 T=
hu, Oct 8, 2015 at 1:22 PM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr">Whether it is valid or not, I wo=
uld just describe it as a &quot;bad smell&quot; or &quot;questionable&quot;=
 if I see ints being stuffed into enums. ie during a code review I would be=
 asking for an explanation.</div></blockquote><div><br></div><div>Definitel=
y, but that&#39;s very different from it being incorrect. A compiler cannot=
 assume anything here, which is why a different facility is not unreasonabl=
e.</div><div><br></div><div>On Thu, Oct 8, 2015 at 1:22 PM, Tony V E=C2=A0<=
span dir=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank=
">tvaneerd@gmail.com</a>&gt;</span>=C2=A0wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr">|&#39;ing for flags is acceptable, but there are somewhat nice wa=
ys to handle it (ie explicitly write | operators - a nicer way to deal with=
 flags would be lovely.)</div></blockquote><div>=C2=A0</div></div><div>If y=
ou explicitly write an | operator with an enum class when representing flag=
s, you&#39;re likely going to be doing a cast internal to the definition of=
 the |. You get the underlying value, perform the operation, and cast it ba=
ck.</div></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&quot; 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 />

--001a11c29966b6cfe005219db957--

.

------=_Part_1121_1242569857.1444336660434
Content-Type: multipart/alternative;
 boundary="----=_Part_1122_1972741731.1444336660435"

------=_Part_1122_1972741731.1444336660435
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 4:57:27 PM UTC+2, Tony V E wrote:
>
> Unfortunately enums value-initialize to 0, regardless of whether 0 is one
> of the enumeration values.
>

Good point.  It could be addressed by requiring that such an "enum union"
shall have an enumerator with value 0 (which would imply that such an enum
needs to have at least one enumerator).  Maybe by even requiring that none
of the enumerators has an initializer (so the enumerator values will always
be 0, 1, 2, ...).  None of these requirements would probably affect the
usability of the construct.

--

---
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_1122_1972741731.1444336660435
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, October 8, 2015 at 4:57:27 PM UTC+2, Tony V E=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>U=
nfortunately enums value-initialize to 0, regardless of whether 0 is one of=
 the enumeration values.</div></div></blockquote><div><br></div><div>Good p=
oint. =C2=A0It could be addressed by requiring that such an &quot;enum unio=
n&quot; shall have an enumerator with value 0 (which would imply that such =
an enum needs to have at least one enumerator). =C2=A0Maybe by even requiri=
ng that none of the enumerators has an initializer (so the enumerator value=
s will always be 0, 1, 2, ...). =C2=A0None of these requirements would prob=
ably affect the usability of the construct.</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&quot; 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_1122_1972741731.1444336660435--
------=_Part_1121_1242569857.1444336660434--

.

On 2015-10-08 16:14, Matt Calabrese wrote:
> representing flags with enums is reasonable to many developers, is
> perfectly fine with respect to the standard, and is frequently done in
> practice.

Abusing an enum type to represent flags is (IMNSHO) terrible practice.
If it's being done "frequently", that to me says that there is a
significant hole in STL, i.e. there should exist an STL type to manage a
flag type (taking the enum type that defines possible flags as its
template argument).

> A compiler cannot and will not assume that your enum only holds the
> explicitly enumerated values

I'm pretty sure that clang begs to differ (i.e. does exactly that in
certain cases, such as deciding if a switch is "complete").

--
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/.

.

------=_Part_1196_2071545411.1444338601154
Content-Type: multipart/alternative;
 boundary="----=_Part_1197_361191916.1444338601154"

------=_Part_1197_361191916.1444338601154
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 10:56:10 PM UTC+2, Matthew Woehlke wrote:
>
> On 2015-10-08 16:14, Matt Calabrese wrote:
> > A compiler cannot and will not assume that your enum only holds the
> > explicitly enumerated values
>
> I'm pretty sure that clang begs to differ (i.e. does exactly that in
> certain cases, such as deciding if a switch is "complete").
>

Yes, currently Clang does, see the mail thread around
http://lists.llvm.org/pipermail/cfe-dev/2015-September/045023.html "Re:
[cfe-dev] Unsound assumptions about exhaustiveness of enum switch cases?"

--

---
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_1197_361191916.1444338601154
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, October 8, 2015 at 10:56:10 PM UTC+2, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-10-08 1=
6:14, Matt Calabrese wrote:
<br>&gt; A compiler cannot and will not assume that your enum only holds th=
e
<br>&gt; explicitly enumerated values
<br>
<br>I&#39;m pretty sure that clang begs to differ (i.e. does exactly that i=
n
<br>certain cases, such as deciding if a switch is &quot;complete&quot;).
<br></blockquote><div><br></div><div>Yes, currently Clang does, see the mai=
l thread around <a href=3D"http://lists.llvm.org/pipermail/cfe-dev/2015-Sep=
tember/045023.html">http://lists.llvm.org/pipermail/cfe-dev/2015-September/=
045023.html</a>=C2=A0&quot;Re: [cfe-dev] Unsound assumptions about exhausti=
veness of enum switch cases?&quot;</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&quot; 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_1197_361191916.1444338601154--
------=_Part_1196_2071545411.1444338601154--

.

--001a1134beb2a9c0e505219e5452
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:
>
> Abusing an enum type to represent flags is (IMNSHO) terrible practice.
>

It's not an abuse nor is it terrible practice -- it's perfectly acceptable
in C++ and more type safe than always using the underlying type directly.
If you don't want that to be valid then you need a different facility,
which is why the OP's suggestion is very reasonable. That you can use enums
as flags isn't really arguable, it's just a fact regarding how C++
currently represents enums. If you don't like that, then that's fine, but
it's how the language currently is and refering to such uses unreasonable
is, quite frankly, unreasonable.

On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> If it's being done "frequently", that to me says that there is a
> significant hole in STL, i.e. there should exist an STL type to manage a
> flag type (taking the enum type that defines possible flags as its
> template argument).


I agree, though unfortunately, enum is closer to such a facility than the
other way around. If you just add a facility for creating flag-like types
(which would also be great), it doesn't change the fact that enum and enum
class can represent other values than those that are explicitly enumerated.
*That* is the underlying issue. Changing existing enum and enum class to
now have such a restriction would break a lot of perfectly valid code. On
the other hand, having a separate and more strict enum, as the OP suggests,
really does solve the problem. In present day C++, if you need such a
strict enum, you cannot do it with enum directly, but instead have to
create your own type.

On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
 wrote:

> > A compiler cannot and will not assume that your enum only holds the
> > explicitly enumerated values
>
> I'm pretty sure that clang begs to differ (i.e. does exactly that in
> certain cases, such as deciding if a switch is "complete").


It doesn't differ -- as I said, compilers can warn based on the handling of
enumerated values, but they are necessarily noisy warnings. Even though
they warn, they cannot actually assume anything (i.e. they can't make
assumptions based on this in a way that would affect code generation, and
they shouldn't produce an error based on such assumptions). If we want to
*actually* have stronger guarantees, we really do need a different
abstraction from what C++ currently provides with respect to enum. Your
notion of what is reasonable just doesn't correspond to the language -- you
can deny that, but you'd just be wrong. This isn't subjective.

--

---
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/.

--001a1134beb2a9c0e505219e5452
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 T=
hu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">Abusing an enum type to represen=
t flags is (IMNSHO) terrible practice.<br></blockquote><div><br></div><div>=
It&#39;s not an abuse nor is it terrible practice -- it&#39;s perfectly acc=
eptable in C++ and more type safe than always using the underlying type dir=
ectly. If you don&#39;t want that to be valid then you need a different fac=
ility, which is why the OP&#39;s suggestion is very reasonable. That you ca=
n use enums as flags isn&#39;t really arguable, it&#39;s just a fact regard=
ing how C++ currently represents enums. If you don&#39;t like that, then th=
at&#39;s fine, but it&#39;s how the language currently is and refering to s=
uch uses unreasonable is, quite frankly, unreasonable.</div><div><br></div>=
<div>On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke=C2=A0<span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke=
..floss@gmail.com</a>&gt;</span>=C2=A0wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If it&#39;s being done &quot;frequently&quot;, that to me says that there i=
s a<br>
significant hole in STL, i.e. there should exist an STL type to manage a<br=
>
flag type (taking the enum type that defines possible flags as its<br>
template argument).</blockquote><div><br></div><div>I agree, though unfortu=
nately, enum is closer to such a facility than the other way around. If you=
 just add a facility for creating flag-like types (which would also be grea=
t), it doesn&#39;t change the fact that enum and enum class can represent o=
ther values than those that are explicitly enumerated. <i>That</i>=C2=A0is =
the underlying issue.=C2=A0Changing existing enum and enum class to now hav=
e such a restriction would break a lot of perfectly valid code. On the othe=
r hand, having a separate and more strict enum, as the OP suggests, really =
does solve the problem. In present day C++, if you need such a strict enum,=
 you cannot do it with enum directly, but instead have to create your own t=
ype.</div><div><br></div><div>On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehl=
ke=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" t=
arget=3D"_blank">mwoehlke.floss@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><span class=3D"">
&gt; A compiler cannot and will not assume that your enum only holds the<br=
>
&gt; explicitly enumerated values<br>
<br>
</span>I&#39;m pretty sure that clang begs to differ (i.e. does exactly tha=
t in<br>
certain cases, such as deciding if a switch is &quot;complete&quot;).</bloc=
kquote><div><br></div><div>It doesn&#39;t differ -- as I said, compilers ca=
n warn based on the handling of enumerated values, but they are necessarily=
 noisy warnings. Even though they warn, they cannot actually assume anythin=
g (i.e. they can&#39;t make assumptions based on this in a way that would a=
ffect code generation, and they shouldn&#39;t produce an error based on suc=
h assumptions). If we want to <i>actually</i> have stronger guarantees, we =
really do need a different abstraction from what C++ currently provides wit=
h respect to enum. Your notion of what is reasonable just doesn&#39;t corre=
spond to the language -- you can deny that, but you&#39;d just be wrong. Th=
is isn&#39;t subjective.</div></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&quot; 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 />

--001a1134beb2a9c0e505219e5452--

.

------=_Part_1169_354350657.1444339373192
Content-Type: multipart/alternative;
 boundary="----=_Part_1170_631444047.1444339373193"

------=_Part_1170_631444047.1444339373193
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 4:14:43 PM UTC-4, Matt Calabrese wrote:
>
> On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> C++ lets you get away with all manor of nonsense through casting.
>> However, "by default", you're not allowed to convert an integer to an enum
>> class. Just as, "by default", you're not allowed to convert a pointer to
>> one type into a pointer to an unrelated type. You need to do a cast, and
>> the result of that cast may or may not be defined (depending on various
>> things).
>>
>
> Converting between unrelated pointer types is very different -- you get
> undefined behavior if the alignments aren't compatible. Converting between
> an enum and its underlying type, on the other hand, is not undefined
> behavior.
>

.... And all you've said is that what I said: casts may or may not be
well-defined code. Casting between pointer types *may* be legal, depending
on their types. And casting between an enum and an integer *may* be legal
code.

Then again, it *may not*. Case in point:
`static_cast<EnumUnsignedInt>(-45);`. That's why you had to stick that
"underlying type" qualifier there.


> It's perfectly well-defined and not an error, and also frequently done in
> practice.
>

Some would call that *bad* practice.


> Just because a conversion requires an explicit cast does not mean it is
> undefined behavior, and your notion of "by default" is meaningless with
> respect to the standard.
>

No, my definitions is what the standard says. Casting is *not* a "by
default" operation, because it requires explicit work by the user to do.
Removing the implicit casting of integers to enums is *half the point* of
`enum class`.


>
>
> On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> In terms of legal C++ code, yes. In terms of *reasonable* C++ code, no.
>>
>
> The C++ standard doesn't care what an individual programmer deems
> "reasonable." It's perfectly acceptable and well-defined. Further,
> representing flags with enums is reasonable to many developers, is
> perfectly fine with respect to the standard, and is frequently done in
> practice. If you want something that doesn't allow this, then an enum is
> not the tool that you want, which is why the OP suggests a new facility.
>

That "new facility" is exactly what `enum class` *was supposed to be*.
Until people like you got a hold of it, of course. They decided that
explicit conversions from integers were important, so they allowed them.
It's not like they couldn't get conversions with non-class enums. But they
decided that it was important to be able to break enums, to give them
values outside the enumerator set.

At the end of the day, C++ is not a safe language. `enum class` proves the
best kind of guarantee it can: a C++-style guarantee.

C++ always leaves a back door. For better or worse.


> On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> Casting a pointer to a `void*` is well-defined too, but that doesn't mean
>> you haven't violated the type system. You've simply done so in a
>> well-defined manor.
>>
>
> A cast being explicit isn't a "violation of the type system."
>

There are very few casts which aren't violations of the type system in some
way. An `enum class` is a promise made by the user about the meaning of a
variable. That's why, by default, it forbids conversions from/to integers.

Violating that promise, however legal that C++ code may be, is a violation
of the type system to me.

A compiler cannot and will not assume that your enum only holds the
> explicitly enumerated values
>

Please pay attention to the point of the thread. I never said that the
compiler would generate code that would be non-functional if the enum value
held a value outside of the enumerators.

We're talking about what *warnings* the compiler should emit during a
switch statement. Here's the assumption we're talking about: should the
compiler assume that an enumerator will contain values outside of its
enumeration for the purposes of deciding if a switch statement is
incomplete?

I do not believe that it should.

--

---
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_1170_631444047.1444339373193
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 8, 2015 at 4:14:43 PM UTC-4, Matt Calabrese wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"e_8Y1R7UDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>C++ lets y=
ou get away with all manor of nonsense through casting. However, &quot;by d=
efault&quot;, you&#39;re not allowed to convert an integer to an enum class=
.. Just as, &quot;by default&quot;, you&#39;re not allowed to convert a poin=
ter to one type into a pointer to an unrelated type. You need to do a cast,=
 and the result of that cast may or may not be defined (depending on variou=
s things).<br></div></blockquote><div><br></div><div>Converting between unr=
elated pointer types is very different -- you get undefined behavior if the=
 alignments aren&#39;t compatible. Converting between an enum and its under=
lying type, on the other hand, is not undefined behavior.</div></div></div>=
</div></blockquote><div><br>... And all you&#39;ve said is that what I said=
: casts may or may not be well-defined code. Casting between pointer types =
<i>may</i> be legal, depending on their types. And casting between an enum =
and an integer <i>may</i> be legal code.<br><br>Then again, it <i>may not</=
i>. Case in point: `static_cast&lt;EnumUnsignedInt&gt;(-45);`. That&#39;s w=
hy you had to stick that &quot;underlying type&quot; qualifier there.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><div>It&#39;s perfectly well-defined and not=
 an error, and also frequently done in practice.</div></div></div></div></b=
lockquote><div><br>Some would call that <i>bad</i> practice.<br>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div>Just because a conversion requires an explicit cas=
t does not mean it is undefined behavior, and your notion of &quot;by defau=
lt&quot; is meaningless with respect to the standard.</div></div></div></di=
v></blockquote><div><br>No, my definitions is what the standard says. Casti=
ng is <i>not</i> a &quot;by default&quot; operation, because it requires ex=
plicit work by the user to do. Removing the implicit casting of integers to=
 enums is <i>half the point</i> of `enum class`.<br>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div><br></div><div><br></div><div>On Thu, Oct 8, 2015 at 12:54 PM,=
 Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"e_8Y1R7UDAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt;</span>=C2=A0<=
wbr>wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div>In terms of legal C++ code, yes. In t=
erms of <i>reasonable</i> C++ code, no.<br></div></blockquote><div><br></di=
v><div>The C++ standard doesn&#39;t care what an individual programmer deem=
s &quot;reasonable.&quot; It&#39;s perfectly acceptable and well-defined. F=
urther, representing flags with enums is reasonable to many developers, is =
perfectly fine with respect to the standard, and is frequently done in prac=
tice. If you want something that doesn&#39;t allow this, then an enum is no=
t the tool that you want, which is why the OP suggests a new facility.</div=
></div></div></div></blockquote><div><br>That &quot;new facility&quot; is e=
xactly what `enum class` <i>was supposed to be</i>. Until people like you g=
ot a hold of it, of course. They decided that explicit conversions from int=
egers were important, so they allowed them. It&#39;s not like they couldn&#=
39;t get conversions with non-class enums. But they decided that it was imp=
ortant to be able to break enums, to give them values outside the enumerato=
r set.<br><br>At the end of the day, C++ is not a safe language. `enum clas=
s` proves the best kind of guarantee it can: a C++-style guarantee.<br><br>=
C++ always leaves a back door. For better or worse.<br>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote"><div> </div><div>On Thu, Oct 8, 2015 at 12:54 PM, Nicol Bolas=C2=
=A0<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"e_8Y1R7UDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">jmck...@gmail.com</a>&gt;</span>=C2=A0<wbr>wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>Casting a pointer to a `void*` is well-defined too, b=
ut that doesn&#39;t mean you haven&#39;t violated the type system. You&#39;=
ve simply done so in a well-defined manor.<br></div></blockquote><div><br><=
/div><div>A cast being explicit isn&#39;t a &quot;violation of the type sys=
tem.&quot;</div></div></div></div></blockquote><div><br>There are very few =
casts which aren&#39;t violations of the type system in some way. An `enum =
class` is a promise made by the user about the meaning of a variable. That&=
#39;s why, by default, it forbids conversions from/to integers.<br><br>Viol=
ating that promise, however legal that C++ code may be, is a violation of t=
he type system to me.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>A compiler cann=
ot and will not assume that your enum only holds the explicitly enumerated =
values</div></div></div></div></blockquote><div><br>Please pay attention to=
 the point of the thread. I never said that the compiler would generate cod=
e that would be non-functional if the enum value held a value outside of th=
e enumerators.<br><br>We&#39;re talking about what <i>warnings</i> the comp=
iler should emit during a switch statement. Here&#39;s the assumption we&#3=
9;re talking about: should the compiler assume that an enumerator will cont=
ain values outside of its enumeration for the purposes of deciding if a swi=
tch statement is incomplete?<br><br>I do not believe that it should.<br></d=
iv>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_1170_631444047.1444339373193--
------=_Part_1169_354350657.1444339373192--

.

------=_Part_1220_1176492299.1444339731660
Content-Type: multipart/alternative;
 boundary="----=_Part_1221_1392475662.1444339731660"

------=_Part_1221_1392475662.1444339731660
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 5:13:13 PM UTC-4, Matt Calabrese wrote:
>
> On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
>>
>> Abusing an enum type to represent flags is (IMNSHO) terrible practice.
>>
>
> It's not an abuse nor is it terrible practice -- it's perfectly acceptable
> in C++ and more type safe than always using the underlying type directly.
>

The fact that something is legal does not mean it isn't terrible practice.
Naked `new` is bad practice, but it's perfectly valid and legal C++.

Using `enum class`es for flags is undeniably popular. But so are a lot of
stupid things. Popularity doesn't justify them.

On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
>
>> If it's being done "frequently", that to me says that there is a
>> significant hole in STL, i.e. there should exist an STL type to manage a
>> flag type (taking the enum type that defines possible flags as its
>> template argument).
>
>
> I agree, though unfortunately, enum is closer to such a facility than the
> other way around. If you just add a facility for creating flag-like types
> (which would also be great), it doesn't change the fact that enum and enum
> class can represent other values than those that are explicitly enumerated.
> *That* is the underlying issue. Changing existing enum and enum class to
> now have such a restriction would break a lot of perfectly valid code. On
> the other hand, having a separate and more strict enum, as the OP suggests,
> really does solve the problem. In present day C++, if you need such a
> strict enum, you cannot do it with enum directly, but instead have to
> create your own type.
>

Why do we need a *third tier* of enum strictness? What problem does it
solve?

The OP's entire motivation thus far is the possible absence of a *compiler
warning*. We should not be adding language features just for a compiler
warning.

--

---
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_1221_1392475662.1444339731660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 8, 2015 at 5:13:13 PM UTC-4, Matt Calabrese wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"HBy1EFDXDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">mwoehlk...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Abusing =
an enum type to represent flags is (IMNSHO) terrible practice.<br></blockqu=
ote><div><br></div><div>It&#39;s not an abuse nor is it terrible practice -=
- it&#39;s perfectly acceptable in C++ and more type safe than always using=
 the underlying type directly.</div></div></div></div></blockquote><div><br=
>The fact that something is legal does not mean it isn&#39;t terrible pract=
ice. Naked `new` is bad practice, but it&#39;s perfectly valid and legal C+=
+.<br><br>Using `enum class`es for flags is undeniably popular. But so are =
a lot of stupid things. Popularity doesn&#39;t justify them.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div>On Thu, Oct 8, 2015 at 1:55 PM, Matthew Woehlke=C2=
=A0<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"HBy1EFDXDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">mwoehlk...@gmail.<wbr>com</a>&gt;</span>=C2=A0wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex">
If it&#39;s being done &quot;frequently&quot;, that to me says that there i=
s a<br>
significant hole in STL, i.e. there should exist an STL type to manage a<br=
>
flag type (taking the enum type that defines possible flags as its<br>
template argument).</blockquote><div><br></div><div>I agree, though unfortu=
nately, enum is closer to such a facility than the other way around. If you=
 just add a facility for creating flag-like types (which would also be grea=
t), it doesn&#39;t change the fact that enum and enum class can represent o=
ther values than those that are explicitly enumerated. <i>That</i>=C2=A0is =
the underlying issue.=C2=A0Changing existing enum and enum class to now hav=
e such a restriction would break a lot of perfectly valid code. On the othe=
r hand, having a separate and more strict enum, as the OP suggests, really =
does solve the problem. In present day C++, if you need such a strict enum,=
 you cannot do it with enum directly, but instead have to create your own t=
ype.</div></div></div></div></blockquote><div><br>Why do we need a <i>third=
 tier</i> of enum strictness? What problem does it solve?<br><br>The OP&#39=
;s entire motivation thus far is the possible absence of a <i>compiler warn=
ing</i>. We should not be adding language features just for a compiler warn=
ing.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_1221_1392475662.1444339731660--
------=_Part_1220_1176492299.1444339731660--

.

--089e0153660869250105219ef8db
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> ... And all you've said is that what I said: casts may or may not be
> well-defined code. Casting between pointer types *may* be legal,
> depending on their types. And casting between an enum and an integer *may*
> be legal code.
>

No, converting back and forth between an enum and it's underlying type is
*always* legal code. Again, this isn't subjective, it's just a fact. That's
how enums are defined in C++. You seem to think that "legal" is somehow
subjective here. It is not. There is a very big difference between personal
conventions and what the standard specifies.

 On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Some would call that *bad* practice.
>

Some call it bad practice, and that's fine for them to do so. Subjective
bad practice != illegal, and this isn't pedanticism. It is a very important
distinction.

On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Removing the implicit casting of integers to enums is *half the point* of
> `enum class`.
>

Turning a cast from implicit to explicit doesn't mean anything at all with
respect to correctness. It prevents implicit conversions, which helps, but
it doesn't make an explicit conversion illegal or even necessarily bad
practice.

On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> That "new facility" is exactly what `enum class` *was supposed to be*.
>

That is *not* what enum class *is* in C++.

On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Until people like you got a hold of it, of course. They decided that
> explicit conversions from integers were important, so they allowed them.
>

Please relax. This isn't the first time in this group that you've taken
things personally. I also didn't have any influence at all on enums, FWIW,
nor do I even necessarily disagree with some of your opinions, so I don't
know what you mean by "people like me." All I'm telling you is what the
standard has to say about things. You can be mad about that, and that's
fine, but it's what C++ is.

On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> There are very few casts which aren't violations of the type system in
> some way. An `enum class` is a promise made by the user about the meaning
> of a variable. That's why, by default, it forbids conversions from/to
> integers.
>
> Violating that promise, however legal that C++ code may be, is a violation
> of the type system to me.
>

You can have whatever definition you want, but your personal opinion of
what is good or bad does not change the standard.

On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> A compiler cannot and will not assume that your enum only holds the
>> explicitly enumerated values
>>
>
> Please pay attention to the point of the thread. I never said that the
> compiler would generate code that would be non-functional if the enum value
> held a value outside of the enumerators.
>
> We're talking about what *warnings* the compiler should emit during a
> switch statement. Here's the assumption we're talking about: should the
> compiler assume that an enumerator will contain values outside of its
> enumeration for the purposes of deciding if a switch statement is
> incomplete?
>
> I do not believe that it should.
>

We are not in disagreement! Both I and the OP fully recognize this. The
problem is that those warnings are necessarily noisy. If you have an actual
type that makes these restrictions then that is no longer the case. Perhaps
more importantly, in user code, holding an enum of a given type currently
does not guarantee that it holds one of the enumerated values. Having a
proper type that restricts those values would be different, but that is
simply not what we have in C++.

--

---
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/.

--089e0153660869250105219ef8db
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 T=
hu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div>... And all you&#39;ve said is that what I =
said: casts may or may not be well-defined code. Casting between pointer ty=
pes <i>may</i> be legal, depending on their types. And casting between an e=
num and an integer <i>may</i> be legal code.<br></div></blockquote><div><br=
></div><div>No, converting back and forth between an enum and it&#39;s unde=
rlying type is <i>always</i>=C2=A0legal code. Again, this isn&#39;t subject=
ive, it&#39;s just a fact. That&#39;s how enums are defined in C++.=C2=A0Yo=
u seem to think that &quot;legal&quot; is somehow subjective here. It is no=
t. There is a very big difference between personal conventions and what the=
 standard specifies.</div><div><br></div><div>=C2=A0On Thu, Oct 8, 2015 at =
2:22 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson=
@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0wrote=
:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex"><div>Some would call that <i>bad</i> practice.<br><=
/div></blockquote><div><br></div><div>Some call it bad practice, and that&#=
39;s fine for them to do so. Subjective bad practice !=3D illegal, and this=
 isn&#39;t pedanticism. It is a very important distinction.</div><div>=C2=
=A0</div><div>On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas=C2=A0<span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>&gt;</span>=C2=A0wrote:</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Removing =
the implicit casting of integers to enums is <i>half the point</i> of `enum=
 class`.<br></div></blockquote><div><br></div><div>Turning a cast from impl=
icit to explicit doesn&#39;t mean anything at all with respect to correctne=
ss. It prevents implicit conversions, which helps, but it doesn&#39;t make =
an explicit conversion illegal or even necessarily bad practice.</div><div>=
<br></div><div>On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas=C2=A0<span dir=
=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmcke=
sson@gmail.com</a>&gt;</span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>=
That &quot;new facility&quot; is exactly what `enum class` <i>was supposed =
to be</i>.</div></blockquote><div><br></div><div>That is <i>not</i>=C2=A0wh=
at enum class <i>is</i> in C++.</div><div><br></div><div>On Thu, Oct 8, 201=
5 at 2:22 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:jmck=
esson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>=C2=A0=
wrote:=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div> Until people like you got a =
hold of it, of course. They decided that explicit conversions from integers=
 were important, so they allowed them.</div></blockquote><div><br></div><di=
v>Please relax. This isn&#39;t the first time in this group that you&#39;ve=
 taken things personally. I also didn&#39;t have any influence at all on en=
ums, FWIW, nor do I even necessarily disagree with some of your opinions, s=
o I don&#39;t know what you mean by &quot;people like me.&quot; All I&#39;m=
 telling you is what the standard has to say about things. You can be mad a=
bout that, and that&#39;s fine, but it&#39;s what C++ is.</div><div><br></d=
iv><div>On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">=
&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmai=
l.com</a>&gt;</span>=C2=A0wrote:=C2=A0=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>The=
re are very few casts which aren&#39;t violations of the type system in som=
e way. An `enum class` is a promise made by the user about the meaning of a=
 variable. That&#39;s why, by default, it forbids conversions from/to integ=
ers.<br><br>Violating that promise, however legal that C++ code may be, is =
a violation of the type system to me.<br></div></blockquote><div><br></div>=
<div>You can have whatever definition you want, but your personal opinion o=
f what is good or bad does not change the standard.</div><div><br></div><di=
v>On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a=
 href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com<=
/a>&gt;</span>=C2=A0wrote:=C2=A0=C2=A0=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
<div>A compiler cannot and will not assume that your enum only holds the ex=
plicitly enumerated values</div></div></div></div></blockquote></span><div>=
<br>Please pay attention to the point of the thread. I never said that the =
compiler would generate code that would be non-functional if the enum value=
 held a value outside of the enumerators.<br><br>We&#39;re talking about wh=
at <i>warnings</i> the compiler should emit during a switch statement. Here=
&#39;s the assumption we&#39;re talking about: should the compiler assume t=
hat an enumerator will contain values outside of its enumeration for the pu=
rposes of deciding if a switch statement is incomplete?<br><br>I do not bel=
ieve that it should.</div></blockquote><div><br></div><div>We are not in di=
sagreement! Both I and the OP fully recognize this. The problem is that tho=
se warnings are necessarily noisy. If you have an actual type that makes th=
ese restrictions then that is no longer the case. Perhaps more importantly,=
 in user code, holding an enum of a given type currently does not guarantee=
 that it holds one of the enumerated values. Having a proper type that rest=
ricts those values would be different, but that is simply not what we have =
in C++.</div></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&quot; 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 />

--089e0153660869250105219ef8db--

.

------=_Part_1913_1994026845.1444398159670
Content-Type: multipart/alternative;
 boundary="----=_Part_1914_2137083244.1444398159670"

------=_Part_1914_2137083244.1444398159670
Content-Type: text/plain; charset=UTF-8

On Thursday, October 8, 2015 at 5:59:01 PM UTC-4, Matt Calabrese wrote:
>
> On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> ... And all you've said is that what I said: casts may or may not be
>> well-defined code. Casting between pointer types *may* be legal,
>> depending on their types. And casting between an enum and an integer
>> *may* be legal code.
>>
>
> No, converting back and forth between an enum and it's underlying type
>

You don't seem to be reading what I actually said.

I said "casting between an enum and an *integer*". There's a reason why I
*didn't* say "underlying type". An integer may or may not be of the
underlying type of any particular enum. And thus, casting between enums and
integers may *or may not* be legal.

Casting between enums and its exact underlying type is as legal as casting
between pointers to T and pointers to a type related to T. Not like casting
between any two pointer types.


> On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> Removing the implicit casting of integers to enums is *half the point*
>> of `enum class`.
>>
>
> Turning a cast from implicit to explicit doesn't mean anything at all with
> respect to correctness. It prevents implicit conversions, which helps, but
> it doesn't make an explicit conversion illegal or even necessarily bad
> practice.
>

Wait a minute... I just checked the standard and realized: no kind of
enumeration allows *implicit* conversion from an integer to an enum. Not in
C++ it doesn't. It never has.

`enum class`es, from a conversion standpoint, are about preventing implicit
conversions *to* integers, not *from* integers.

So both of us are proceeding from a false premise; it has never been easy
to accidentally make an enum (of any kind) contain a non-enumerator value.


> On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> That "new facility" is exactly what `enum class` *was supposed to be*.
>>
>
> That is *not* what enum class *is* in C++.
>

I've looked back at N2213 and I've discovered that it did make allowances
for explicit conversion (though it didn't have the modern wording for it)
The older N1719 had odd wording, and it's not clear what it meant either
way.


> On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> A compiler cannot and will not assume that your enum only holds the
>>> explicitly enumerated values
>>>
>>
>> Please pay attention to the point of the thread. I never said that the
>> compiler would generate code that would be non-functional if the enum value
>> held a value outside of the enumerators.
>>
>> We're talking about what *warnings* the compiler should emit during a
>> switch statement. Here's the assumption we're talking about: should the
>> compiler assume that an enumerator will contain values outside of its
>> enumeration for the purposes of deciding if a switch statement is
>> incomplete?
>>
>> I do not believe that it should.
>>
>
> We are not in disagreement! Both I and the OP fully recognize this. The
> problem is that those warnings are necessarily noisy. If you have an actual
> type that makes these restrictions then that is no longer the case.
>

I'm not seeing the point of agreement here. I do not agree that we should
add a language feature for the primary purpose of making compilers warn
correctly about improper usage.

That's attribute territory, not *language* territory. Use a
compiler-specific attribute to annotate an `enum class` to be "really and
truly I pinky-swear" what it says it is. Or one to annotate a switch
statement.

Fixing warnings is not what language features should do.


> Perhaps more importantly, in user code, holding an enum of a given type
> currently does not guarantee that it holds one of the enumerated values.
> Having a proper type that restricts those values would be different, but
> that is simply not what we have in C++.
>

Yes, we also don't have ways to make users use smart pointers. Or ways to
prevent people from casting pointers to `void*`. Or any number of things to
stop people from doing dangerous things in the language.

C++ isn't safe. You can write safe code in it, but that means not doing
certain things.

`enum class` is as safe an enumerator as C++ *ought* to provide. It
prevents unsafe casts to the extent that C++ prevents unsafe casts. That
is, you can still do them, but not by accident. Why? Because every now and
then... that conversion is exactly what you need.

Maybe you're getting a C enumerator from a C library. And you want to
convert it into a proper scoped enumerator, since you don't want to expose
C++ programmers to some C enum. And you're certain that the given value
matches one of the `enum class` enumerators; maybe you even have some
checks to verify that. What's wrong with the explicit conversion in this
case?

Nothing. It's semantically correct, and it still fulfills the promise of
the enum.

C++ always leaves back doors like this, just in case a user has to do
something odd. But that does not mean that users should expect that an enum
variable will have values outside of its enumerators. And it *most
certainly* does not mean that compilers and other static analysis tools
should issue warnings under such assumptions.

>

--

---
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_1914_2137083244.1444398159670
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, October 8, 2015 at 5:59:01 PM UTC-4, Matt Calabrese wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
mII23M_ZDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>... And all=
 you&#39;ve said is that what I said: casts may or may not be well-defined =
code. Casting between pointer types <i>may</i> be legal, depending on their=
 types. And casting between an enum and an integer <i>may</i> be legal code=
..<br></div></blockquote><div><br></div><div>No, converting back and forth b=
etween an enum and it&#39;s underlying type </div></div></div></div></block=
quote><div><br>You don&#39;t seem to be reading what I actually said.<br><b=
r>I said &quot;casting between an enum and an <u>integer</u>&quot;. There&#=
39;s a reason why I <i>didn&#39;t</i> say &quot;underlying type&quot;. An i=
nteger may or may not be of the underlying type of any particular enum. And=
 thus, casting between enums and integers may <i>or may not</i> be legal.<b=
r><br>Casting between enums and its exact underlying type is as legal as ca=
sting between pointers to T and pointers to a type related to T. Not like c=
asting between any two pointer types.<br></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote"><div> </div><div>On Thu, Oct 8, 2015 at 2:22 PM, Nicol Bolas=C2=A0<=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"mII23M_ZDAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">jmck...@gmail.com</a>&gt;</span>=C2=A0<wbr>wrote:</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div>Removing the implicit casting of integers to enums is <i>=
half the point</i> of `enum class`.<br></div></blockquote><div><br></div><d=
iv>Turning a cast from implicit to explicit doesn&#39;t mean anything at al=
l with respect to correctness. It prevents implicit conversions, which help=
s, but it doesn&#39;t make an explicit conversion illegal or even necessari=
ly bad practice.</div></div></div></div></blockquote><div><br>Wait a minute=
.... I just checked the standard and realized: no kind of enumeration allows=
 <i>implicit</i> conversion from an integer to an enum. Not in C++ it doesn=
&#39;t. It never has.<br><br>`enum class`es, from a conversion standpoint, =
are about preventing implicit conversions <i>to</i> integers, not <i>from</=
i> integers.<br><br>So both of us are proceeding from a false premise; it h=
as never been easy to accidentally make an enum (of any kind) contain a non=
-enumerator value.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>On Thu, Oct 8, =
2015 at 2:22 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"mII23M_ZDAAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&g=
t;</span>=C2=A0<wbr>wrote:=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div>That &quot;new =
facility&quot; is exactly what `enum class` <i>was supposed to be</i>.</div=
></blockquote><div><br></div><div>That is <i>not</i>=C2=A0what enum class <=
i>is</i> in C++.</div></div></div></div></blockquote><div><br>I&#39;ve look=
ed back at N2213 and I&#39;ve discovered that it did make allowances for ex=
plicit conversion (though it didn&#39;t have the modern wording for it) The=
 older N1719 had odd wording, and it&#39;s not clear what it meant either w=
ay.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div></div><div>On Thu, Oct 8, 2015 a=
t 2:22 PM, Nicol Bolas=C2=A0<span dir=3D"ltr">&lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"mII23M_ZDAAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt;</spa=
n>=C2=A0<wbr>wrote:=C2=A0=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>A compiler ca=
nnot and will not assume that your enum only holds the explicitly enumerate=
d values</div></div></div></div></blockquote></span><div><br>Please pay att=
ention to the point of the thread. I never said that the compiler would gen=
erate code that would be non-functional if the enum value held a value outs=
ide of the enumerators.<br><br>We&#39;re talking about what <i>warnings</i>=
 the compiler should emit during a switch statement. Here&#39;s the assumpt=
ion we&#39;re talking about: should the compiler assume that an enumerator =
will contain values outside of its enumeration for the purposes of deciding=
 if a switch statement is incomplete?<br><br>I do not believe that it shoul=
d.</div></blockquote><div><br></div><div>We are not in disagreement! Both I=
 and the OP fully recognize this. The problem is that those warnings are ne=
cessarily noisy. If you have an actual type that makes these restrictions t=
hen that is no longer the case.</div></div></div></div></blockquote><div><b=
r>I&#39;m not seeing the point of agreement here. I do not agree that we sh=
ould add a language feature for the primary purpose of making compilers war=
n correctly about improper usage.<br><br>That&#39;s attribute territory, no=
t <i>language</i> territory. Use a compiler-specific attribute to annotate =
an `enum class` to be &quot;really and truly I pinky-swear&quot; what it sa=
ys it is. Or one to annotate a switch statement.<br><br>Fixing warnings is =
not what language features should do.<br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v>Perhaps more importantly, in user code, holding an enum of a given type c=
urrently does not guarantee that it holds one of the enumerated values. Hav=
ing a proper type that restricts those values would be different, but that =
is simply not what we have in C++.</div></div></div></div></blockquote><div=
><br>Yes, we also don&#39;t have ways to make users use smart pointers. Or =
ways to prevent people from casting pointers to `void*`. Or any number of t=
hings to stop people from doing dangerous things in the language.<br><br>C+=
+ isn&#39;t safe. You can write safe code in it, but that means not doing c=
ertain things.<br><br>`enum class` is as safe an enumerator as C++ <i>ought=
</i> to provide. It prevents unsafe casts to the extent that C++ prevents u=
nsafe casts. That is, you can still do them, but not by accident. Why? Beca=
use every now and then... that conversion is exactly what you need.<br><br>=
Maybe you&#39;re getting a C enumerator from a C library. And you want to c=
onvert it into a proper scoped enumerator, since you don&#39;t want to expo=
se C++ programmers to some C enum. And you&#39;re certain that the given va=
lue matches one of the `enum class` enumerators; maybe you even have some c=
hecks to verify that. What&#39;s wrong with the explicit conversion in this=
 case?<br><br>Nothing. It&#39;s semantically correct, and it still fulfills=
 the promise of the enum.<br><br>C++ always leaves back doors like this, ju=
st in case a user has to do something odd. But that does not mean that user=
s should expect that an enum variable will have values outside of its enume=
rators. And it <i>most certainly</i> does not mean that compilers and other=
 static analysis tools should issue warnings under such assumptions.<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_1914_2137083244.1444398159670--
------=_Part_1913_1994026845.1444398159670--

.