------=_Part_130_1994407586.1465206383861
Content-Type: multipart/alternative;
 boundary="----=_Part_131_998261508.1465206383861"

------=_Part_131_998261508.1465206383861
Content-Type: text/plain; charset=UTF-8

What shall the behaviour be if a variable of [[exhaustive]] enum type E is
assigned a value that isn't among E's enumerator values (but still within
the range of E's enumeration values)?  I guess it should be undefined
behaviour, as otherwise suppressing warnings about missing switch cases
would appear unjustified to me.  (And if should be UB, it would make sense
to require that E has a least one enumerator with value zero, to avoid UB
in zero-initialization.  Note that
<https://groups.google.com/a/isocpp.org/d/topic/std-proposals/XlT6rFrCL4M/discussion>
is a previous, somewhat similar discussion, which aimed at addressing the
switch warning problem by concentrating on the enum's range of enumeration
values.)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20fecf41-2bef-4b0f-bad5-dc1873b95e4a%40isocpp.org.

------=_Part_131_998261508.1465206383861
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What shall the behaviour be if a variable of [[exhaustive]=
] enum type E is assigned a value that isn&#39;t among E&#39;s enumerator v=
alues (but still within the range of E&#39;s enumeration values)?=C2=A0 I g=
uess it should be undefined behaviour, as otherwise suppressing warnings ab=
out missing switch cases would appear unjustified to me.=C2=A0 (And if shou=
ld be UB, it would make sense to require that E has a least one enumerator =
with value zero, to avoid UB in zero-initialization.=C2=A0 Note that &lt;ht=
tps://groups.google.com/a/isocpp.org/d/topic/std-proposals/XlT6rFrCL4M/disc=
ussion&gt; is a previous, somewhat similar discussion, which aimed at addre=
ssing the switch warning problem by concentrating on the enum&#39;s range o=
f enumeration values.)<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20fecf41-2bef-4b0f-bad5-dc1873b95e4a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20fecf41-2bef-4b0f-bad5-dc1873b95e4a=
%40isocpp.org</a>.<br />

------=_Part_131_998261508.1465206383861--

------=_Part_130_1994407586.1465206383861--

.

Em segunda-feira, 6 de junho de 2016, =C3=A0s 02:46:23 CDT,=20
stephan.bergmann.secondary via ISO C++ Standard - Future Proposals escreveu=
:
> (And if should be UB, it would make sense=20
> to require that E has a least one enumerator with value zero, to avoid UB=
=20
> in zero-initialization.

Well, you don't need to require it if you require value-initialisation to=
=20
something valid.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4396616.rVkoEtg48m%40tjmaciei-mobl1.

.

------=_Part_427_98960087.1465216843316
Content-Type: multipart/alternative;
 boundary="----=_Part_428_118971108.1465216843316"

------=_Part_428_118971108.1465216843316
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, June 6, 2016 at 2:20:08 PM UTC+2, Thiago Macieira wrote:
>
> Em segunda-feira, 6 de junho de 2016, =C3=A0s 02:46:23 CDT,=20
> stephan.bergmann.secondary via ISO C++ Standard - Future Proposals=20
> escreveu:=20
> > (And if should be UB, it would make sense=20
> > to require that E has a least one enumerator with value zero, to avoid=
=20
> UB=20
> > in zero-initialization.=20
>
> Well, you don't need to require it if you require value-initialisation to=
=20
> something valid.
>

Defining value-initialization is not enough, as zero-initialization of=20
objects of enum type can happen too, e.g., during static initialization.=20
And defining zero-initialization of such an enum type as anything non-zero=
=20
is probably rather awkward, both for the standard and for implementations.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/782321be-ad4f-46b6-b548-0fe4032cc3d7%40isocpp.or=
g.

------=_Part_428_118971108.1465216843316
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, June 6, 2016 at 2:20:08 PM UTC+2, Thiago Maciei=
ra wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em segunda-feira, 6 d=
e junho de 2016, =C3=A0s 02:46:23 CDT,=20
<br>stephan.bergmann.secondary via ISO C++ Standard - Future Proposals escr=
eveu:
<br>&gt; (And if should be UB, it would make sense=20
<br>&gt; to require that E has a least one enumerator with value zero, to a=
void UB=20
<br>&gt; in zero-initialization.
<br>
<br>Well, you don&#39;t need to require it if you require value-initialisat=
ion to=20
<br>something valid.<br></blockquote><div><br>Defining value-initialization=
 is not enough, as zero-initialization of objects of enum type can happen t=
oo, e.g., during static initialization. And defining zero-initialization of=
 such an enum type as anything non-zero is probably rather awkward, both fo=
r the standard and for implementations.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/782321be-ad4f-46b6-b548-0fe4032cc3d7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/782321be-ad4f-46b6-b548-0fe4032cc3d7=
%40isocpp.org</a>.<br />

------=_Part_428_118971108.1465216843316--

------=_Part_427_98960087.1465216843316--

.

Em segunda-feira, 6 de junho de 2016, =C3=A0s 05:40:43 PDT,=20
stephan.bergmann.secondary via ISO C++ Standard - Future Proposals escreveu=
:
> On Monday, June 6, 2016 at 2:20:08 PM UTC+2, Thiago Macieira wrote:
> > Em segunda-feira, 6 de junho de 2016, =C3=A0s 02:46:23 CDT,
> > stephan.bergmann.secondary via ISO C++ Standard - Future Proposals
> >=20
> > escreveu:
> > > (And if should be UB, it would make sense
> > > to require that E has a least one enumerator with value zero, to avoi=
d
> >=20
> > UB
> >=20
> > > in zero-initialization.
> >=20
> > Well, you don't need to require it if you require value-initialisation =
to
> > something valid.
>=20
> Defining value-initialization is not enough, as zero-initialization of
> objects of enum type can happen too, e.g., during static initialization.
> And defining zero-initialization of such an enum type as anything non-zer=
o
> is probably rather awkward, both for the standard and for implementations=
..

I understand that we'll zero-initialisation as a step in the value-
initialisation procedure. But as long as the exhaustive enum isn't *left*=
=20
zero-intialised, it is not a problem.

The point is: if it's exhaustive, it shall not contain any value not in the=
=20
list. Which means you mustn't leave it zero-initialised. I don't see the=20
problem.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6218347.zGopjEXeml%40tjmaciei-mobl1.

.

------=_Part_4195_830739624.1465241136968
Content-Type: multipart/alternative;
 boundary="----=_Part_4196_129130049.1465241136968"

------=_Part_4196_129130049.1465241136968
Content-Type: text/plain; charset=UTF-8

On Monday, June 6, 2016 at 6:27:48 PM UTC+2, Thiago Macieira wrote:
>
> The point is: if it's exhaustive, it shall not contain any value not in
> the
> list. Which means you mustn't leave it zero-initialised. I don't see the
> problem.
>

What shall be the meaning of

#include <iostream>
enum [[exhaustive]] E { E1 = 1 };
E f();
E e = f();
E f() {
 std::cout << +e << '\n';
 return E1;
}
int main() {}



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a503757-aa81-4946-a43b-dcb2765431fc%40isocpp.org.

------=_Part_4196_129130049.1465241136968
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, June 6, 2016 at 6:27:48 PM UTC+2, Thiago Maciei=
ra wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The point is: if it&#=
39;s exhaustive, it shall not contain any value not in the=20
<br>list. Which means you mustn&#39;t leave it zero-initialised. I don&#39;=
t see the=20
<br>problem.
<br></blockquote><div><br></div><div>What shall be the meaning of</div><div=
><br></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D"s=
ubprettyprint">#include &lt;iostream&gt;</div><div class=3D"subprettyprint"=
>enum [[exhaustive]] E { E1 =3D 1 };</div><div class=3D"subprettyprint">E f=
();</div><div class=3D"subprettyprint">E e =3D f();</div><div class=3D"subp=
rettyprint">E f() {</div><div class=3D"subprettyprint">=C2=A0std::cout &lt;=
&lt; +e &lt;&lt; &#39;\n&#39;;</div><div class=3D"subprettyprint">=C2=A0ret=
urn E1;</div><div class=3D"subprettyprint">}</div><div class=3D"subprettypr=
int">int main() {}</div></div></code></div><br>=C2=A0</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a503757-aa81-4946-a43b-dcb2765431fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a503757-aa81-4946-a43b-dcb2765431fc=
%40isocpp.org</a>.<br />

------=_Part_4196_129130049.1465241136968--

------=_Part_4195_830739624.1465241136968--

.

Em segunda-feira, 6 de junho de 2016, =C3=A0s 12:25:36 PDT,=20
stephan.bergmann.secondary via ISO C++ Standard - Future Proposals escreveu=
:
> On Monday, June 6, 2016 at 6:27:48 PM UTC+2, Thiago Macieira wrote:
> > The point is: if it's exhaustive, it shall not contain any value not in
> > the
> > list. Which means you mustn't leave it zero-initialised. I don't see th=
e
> > problem.
>=20
> What shall be the meaning of
>=20
> #include <iostream>
> enum [[exhaustive]] E { E1 =3D 1 };
> E f();
> E e =3D f();
> E f() {
>  std::cout << +e << '\n';
>  return E1;
> }
> int main() {}

The same as what would happen if you returned from a [[noreturn]] function.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2607721.CBxtHfUszv%40tjmaciei-mobl1.

.

------=_Part_1567_1265595625.1465290242976
Content-Type: multipart/alternative;
 boundary="----=_Part_1568_1891022750.1465290242976"

------=_Part_1568_1891022750.1465290242976
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 7, 2016 at 2:24:07 AM UTC+2, Thiago Macieira wrote:
>
> Em segunda-feira, 6 de junho de 2016, =C3=A0s 12:25:36 PDT,=20
> stephan.bergmann.secondary via ISO C++ Standard - Future Proposals=20
> escreveu:=20
> > On Monday, June 6, 2016 at 6:27:48 PM UTC+2, Thiago Macieira wrote:=20
> > > The point is: if it's exhaustive, it shall not contain any value not=
=20
> in=20
> > > the=20
> > > list. Which means you mustn't leave it zero-initialised. I don't see=
=20
> the=20
> > > problem.=20
> >=20
> > What shall be the meaning of=20
> >=20
> > #include <iostream>=20
> > enum [[exhaustive]] E { E1 =3D 1 };=20
> > E f();=20
> > E e =3D f();=20
> > E f() {=20
> >  std::cout << +e << '\n';=20
> >  return E1;=20
> > }=20
> > int main() {}=20
>
> The same as what would happen if you returned from a [[noreturn]] functio=
n.


Not sure why you come up with an analogy to [[noreturn]] here.  But anyway,=
=20
if the intention is to make zero-initialization of an [[exhaustive]] enum=
=20
that has no enumerator with value zero undefined behavior, that needs to be=
=20
included in P0375R0's proposed changes to the standard.=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c6625cb3-68fb-4bc2-baee-f972ecdd13a5%40isocpp.or=
g.

------=_Part_1568_1891022750.1465290242976
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 7, 2016 at 2:24:07 AM UTC+2, Thiago Macie=
ira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em segunda-feira, 6 =
de junho de 2016, =C3=A0s 12:25:36 PDT,=20
<br>stephan.bergmann.secondary via ISO C++ Standard - Future Proposals escr=
eveu:
<br>&gt; On Monday, June 6, 2016 at 6:27:48 PM UTC+2, Thiago Macieira wrote=
:
<br>&gt; &gt; The point is: if it&#39;s exhaustive, it shall not contain an=
y value not in
<br>&gt; &gt; the
<br>&gt; &gt; list. Which means you mustn&#39;t leave it zero-initialised. =
I don&#39;t see the
<br>&gt; &gt; problem.
<br>&gt;=20
<br>&gt; What shall be the meaning of
<br>&gt;=20
<br>&gt; #include &lt;iostream&gt;
<br>&gt; enum [[exhaustive]] E { E1 =3D 1 };
<br>&gt; E f();
<br>&gt; E e =3D f();
<br>&gt; E f() {
<br>&gt; =C2=A0std::cout &lt;&lt; +e &lt;&lt; &#39;\n&#39;;
<br>&gt; =C2=A0return E1;
<br>&gt; }
<br>&gt; int main() {}
<br>
<br>The same as what would happen if you returned from a [[noreturn]] funct=
ion.</blockquote><div><br>Not sure why you come up with an analogy to [[nor=
eturn]] here.=C2=A0 But anyway, if the intention is to make zero-initializa=
tion of an [[exhaustive]] enum that has no enumerator with value zero undef=
ined behavior, that needs to be included in P0375R0&#39;s proposed changes =
to the standard. <br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c6625cb3-68fb-4bc2-baee-f972ecdd13a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c6625cb3-68fb-4bc2-baee-f972ecdd13a5=
%40isocpp.org</a>.<br />

------=_Part_1568_1891022750.1465290242976--

------=_Part_1567_1265595625.1465290242976--

.

------=_Part_228_1661650514.1465306841918
Content-Type: multipart/alternative;
 boundary="----=_Part_229_859134496.1465306841918"

------=_Part_229_859134496.1465306841918
Content-Type: text/plain; charset=UTF-8

Personally, I think this whole proposal is backwards.

Compilers should assume that enums are "exhaustive" *by default* (unless
they specify no enumerators, obviously). After all, many compilers already
issue warnings if you switch over an enum but miss some of the enumerators.

There should instead be an attribute to annotate non-exhaustive enums, thus
shutting off such warnings. It would also allow us to shut off such
warnings conditionally, at the cite where the enum is used:

switch([[unrestricted]] some_enum)

Oh, and it avoids the whole zero/default-initialization problem, because it
allows regular enums to retain their current behavior.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e8c063b3-9d87-4bae-aa1d-9a12125d5181%40isocpp.org.

------=_Part_229_859134496.1465306841918
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Personally, I think this whole proposal is backwards.<br><=
br>Compilers should assume that enums are &quot;exhaustive&quot; <i>by defa=
ult</i> (unless they specify no enumerators, obviously). After all, many co=
mpilers already issue warnings if you switch over an enum but miss some of =
the enumerators.<br><br>There should instead be an attribute to annotate no=
n-exhaustive enums, thus shutting off such warnings. It would also allow us=
 to shut off such warnings conditionally, at the cite where the enum is use=
d:<br>=C2=A0=C2=A0=C2=A0 <br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
 solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">switch</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">([[</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">unrestricted</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">]]</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 some_enum</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span></div></code></div><br>Oh, and it avoids the whole zero/default-ini=
tialization problem, because it allows regular enums to retain their curren=
t behavior.</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e8c063b3-9d87-4bae-aa1d-9a12125d5181%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e8c063b3-9d87-4bae-aa1d-9a12125d5181=
%40isocpp.org</a>.<br />

------=_Part_229_859134496.1465306841918--

------=_Part_228_1661650514.1465306841918--

.

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

On Mon, Jun 6, 2016 at 2:46 AM, stephan.bergmann.secondary via ISO C++
Standard - Future Proposals <std-proposals@isocpp.org> wrote:

> What shall the behaviour be if a variable of [[exhaustive]] enum type E is
> assigned a value that isn't among E's enumerator values (but still within
> the range of E's enumeration values)?  I guess it should be undefined
> behaviour, as otherwise suppressing warnings about missing switch cases
> would appear unjustified to me.  (And if should be UB, it would make sense
> to require that E has a least one enumerator with value zero, to avoid UB
> in zero-initialization.  Note that <
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/XlT6rFrCL4M/discussion>
> is a previous, somewhat similar discussion, which aimed at addressing the
> switch warning problem by concentrating on the enum's range of enumeration
> values.)
>

Regarding out-of-range values, I don't see 0-init as a problem (nor
creation of an uninitialized enum on the stack). First, it's not a problem
because the paper doesn't actually change the valid range of values of the
enum. By that I mean it's still allowable to read and write values in the
*actual* full range of the enum or enum class. All it does is provide a
hint for compiler warnings. Even if it were more than that and introduced
UB, the UB should be if the value is *read* rather than the if
representation is ever a value not identified as one of the enum's
constants. In other words, hypothetically, if this proposal did do more
than simply provide a hint for warnings, there wouldn't be UB from having a
0-initialized instance of your enum (assuming your enum doesn't have a
named constant with the value 0), however, if you *read* the value of an
enum when it held a value that's not one of the named constants, then
*that* would be UB. Think of it like an uninitialized bool on the stack.
There is nothing illegal about not initializing it, however *reading* from
it is UB unless you first assign it true or false.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnH9iW%2Bj%2BLyvChAAZZgGW2zuOSM9tfDmZQ9gBOiZqz5gA%40mail.gmail.com.

--001a113d12688dc5430534b510c0
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 M=
on, Jun 6, 2016 at 2:46 AM, stephan.bergmann.secondary via ISO C++ Standard=
 - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr">What shall the behaviour be if a variable of [[exhausti=
ve]] enum type E is assigned a value that isn&#39;t among E&#39;s enumerato=
r values (but still within the range of E&#39;s enumeration values)?=C2=A0 =
I guess it should be undefined behaviour, as otherwise suppressing warnings=
 about missing switch cases would appear unjustified to me.=C2=A0 (And if s=
hould be UB, it would make sense to require that E has a least one enumerat=
or with value zero, to avoid UB in zero-initialization.=C2=A0 Note that &lt=
;<a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Xl=
T6rFrCL4M/discussion">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/XlT6rFrCL4M/discussion</a>&gt; is a previous, somewhat similar disc=
ussion, which aimed at addressing the switch warning problem by concentrati=
ng on the enum&#39;s range of enumeration values.)</div></blockquote><div><=
br></div><div>Regarding out-of-range values, I don&#39;t see 0-init as a pr=
oblem (nor creation of an uninitialized enum on the stack). First, it&#39;s=
 not a problem because the paper doesn&#39;t actually change the valid rang=
e of values of the enum. By that I mean it&#39;s still allowable to read an=
d write values in the *actual* full range of the enum or enum class. All it=
 does is provide a hint for compiler warnings. Even if it were more than th=
at and introduced UB, the UB should be if the value is *read* rather than t=
he if representation is ever a value not identified as one of the enum&#39;=
s constants. In other words, hypothetically, if this proposal did do more t=
han simply provide a hint for warnings, there wouldn&#39;t be UB from havin=
g a 0-initialized instance of your enum (assuming your enum doesn&#39;t hav=
e a named constant with the value 0), however, if you *read* the value of a=
n enum when it held a value that&#39;s not one of the named constants, then=
 *that* would be UB. Think of it like an uninitialized bool on the stack. T=
here is nothing illegal about not initializing it, however *reading* from i=
t is UB unless you first assign it true or false.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnH9iW%2Bj%2BLyvChAAZZgGW2zuOSM=
9tfDmZQ9gBOiZqz5gA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnH9iW%=
2Bj%2BLyvChAAZZgGW2zuOSM9tfDmZQ9gBOiZqz5gA%40mail.gmail.com</a>.<br />

--001a113d12688dc5430534b510c0--

.

------=_Part_328_1102768098.1465398116379
Content-Type: multipart/alternative;
 boundary="----=_Part_329_1504847035.1465398116380"

------=_Part_329_1504847035.1465398116380
Content-Type: text/plain; charset=UTF-8

On Tuesday, June 7, 2016 at 9:40:42 AM UTC-4, Nicol Bolas wrote:
>
> Personally, I think this whole proposal is backwards.
>
> Compilers should assume that enums are "exhaustive" *by default* (unless
> they specify no enumerators, obviously). After all, many compilers already
> issue warnings if you switch over an enum but miss some of the enumerators.
>

You're suggesting that compilers should eliminate the current warning if
you don't
include a default case but do include all the specified enumerators?
 That's the
warning that this proposal wants to disable selectively.

There should instead be an attribute to annotate non-exhaustive enums, thus
> shutting off such warnings. It would also allow us to shut off such
> warnings conditionally, at the cite where the enum is used:
>
> switch([[unrestricted]] some_enum)
>
> Oh, and it avoids the whole zero/default-initialization problem, because
> it allows regular enums to retain their current behavior.
>

I don't understand what you're suggesting here.  Are you suggesting that
this
would suppress the switch warnings completely?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40d7e0b1-0b3f-4136-a071-61979864750c%40isocpp.org.

------=_Part_329_1504847035.1465398116380
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 7, 2016 at 9:40:42 AM UTC-4, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Persona=
lly, I think this whole proposal is backwards.<br><br>Compilers should assu=
me that enums are &quot;exhaustive&quot; <i>by default</i> (unless they spe=
cify no enumerators, obviously). After all, many compilers already issue wa=
rnings if you switch over an enum but miss some of the enumerators.<br></di=
v></blockquote><div><br></div><div>You&#39;re suggesting that compilers sho=
uld eliminate the current warning if you don&#39;t</div><div>include a defa=
ult case but do include all the specified enumerators? =C2=A0That&#39;s the=
</div><div>warning that this proposal wants to disable selectively.</div><d=
iv><br></div><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">=
There should instead be an attribute to annotate non-exhaustive enums, thus=
 shutting off such warnings. It would also allow us to shut off such warnin=
gs conditionally, at the cite where the enum is used:<br>=C2=A0=C2=A0=C2=A0=
 <br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><span style=3D"color:#008">switch</span><span style=3D"color:#660">([[</s=
pan><span style=3D"color:#000">unrestricted</span><span style=3D"color:#660=
">]]</span><span style=3D"color:#000"> some_enum</span><span style=3D"color=
:#660">)</span></div></code></div><br>Oh, and it avoids the whole zero/defa=
ult-initialization problem, because it allows regular enums to retain their=
 current behavior.</div></blockquote><div><br></div><div>I don&#39;t unders=
tand what you&#39;re suggesting here. =C2=A0Are you suggesting that this</d=
iv><div>would suppress the switch warnings completely?</div><div><br></div>=
</div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40d7e0b1-0b3f-4136-a071-61979864750c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40d7e0b1-0b3f-4136-a071-61979864750c=
%40isocpp.org</a>.<br />

------=_Part_329_1504847035.1465398116380--

------=_Part_328_1102768098.1465398116379--

.