------=_Part_858_16524770.1359423069926
Content-Type: text/plain; charset=ISO-8859-1

I'd like to propose a string-switch. Every constant expression (including
string-literals) from type char[N]/const char[N] could be used as a label.
The variable should be from type const char*.

const char* s = ...;
switch (s)
{
default:
break;
case "foo":
break;
case "bar":
break;
case "baz":
break;
}

This would obviously be much, much more efficient than a ordinary if-else
chain. A handwritten switch/if-else-chain over single characters could
probably be equally efficient, but is very hard to write and very hard to
adapt to new labels. A std::map would be relatively efficient, but not as
good as the compiler can do here due to code generation and optimization
limitations. I wrote a little benchmark a while ago, which supports
this: http://ideone.com/p3hHG1 The results differ quite a lot between
different compilers (which still makes me think I made a mistake
somewhere...), but the hand-written algorithms are much faster with every
configuration. So in the end, I think, this would be a great feature which
could be introduced easily and without breaking any code.

I'd love to hear feedback from you. :)

--

---
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/?hl=en.



------=_Part_858_16524770.1359423069926
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'd like to propose a string-switch. Every constant expression (including s=
tring-literals) from type char[N]/const char[N] could be used as a label. T=
he variable should be from type const char*.<div><br></div><div>const char*=
 s =3D ...;</div><div>switch (s)</div><div>{</div><div>default:</div><div>b=
reak;</div><div>case "foo":</div><div>break;</div><div>case "bar":</div><di=
v>break;</div><div>case "baz":</div><div>break;</div><div>}</div><div><br><=
/div><div>This would obviously be much, much more efficient than a ordinary=
 if-else chain. A handwritten switch/if-else-chain over single characters c=
ould probably be equally efficient, but is very hard to write and very hard=
 to adapt to new labels. A std::map would be relatively efficient, but not =
as good as the compiler can do here due to code generation and optimization=
 limitations. I wrote a little benchmark a while ago, which supports this:&=
nbsp;http://ideone.com/p3hHG1 The results differ quite a lot between differ=
ent compilers (which still makes me think I made a mistake somewhere...), b=
ut the hand-written algorithms are much faster with every configuration. So=
 in the end, I think, this would be a great feature which could be introduc=
ed easily and without breaking any code.</div><div><br></div><div>I'd love =
to hear feedback from you. :)</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_858_16524770.1359423069926--

.

Also check out http://llvm.org/docs/doxygen/html/StringSwitch_8h_source.html.

On Mon, Jan 28, 2013 at 5:31 PM,  <cooky451@gmail.com> wrote:
> I'd like to propose a string-switch. Every constant expression (including
> string-literals) from type char[N]/const char[N] could be used as a label.
> The variable should be from type const char*.
>
> const char* s = ...;
> switch (s)
> {
> default:
> break;
> case "foo":
> break;
> case "bar":
> break;
> case "baz":
> break;
> }
>
> This would obviously be much, much more efficient than a ordinary if-else
> chain. A handwritten switch/if-else-chain over single characters could
> probably be equally efficient, but is very hard to write and very hard to
> adapt to new labels. A std::map would be relatively efficient, but not as
> good as the compiler can do here due to code generation and optimization
> limitations. I wrote a little benchmark a while ago, which supports this:
> http://ideone.com/p3hHG1 The results differ quite a lot between different
> compilers (which still makes me think I made a mistake somewhere...), but
> the hand-written algorithms are much faster with every configuration. So in
> the end, I think, this would be a great feature which could be introduced
> easily and without breaking any code.
>
> I'd love to hear feedback from you. :)
>
> --
>
> ---
> 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/?hl=en.
>
>

--

---
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/?hl=en.



.

------=_Part_1019_4180909.1359423487451
Content-Type: text/plain; charset=ISO-8859-1

I would edit my post, but mailing lists don't like that. :p

An alternative and more generic approach would be switch (begin : end),
which would work for everything where *begin is an integral type. The
labels must have the type (*begin)[N] and of course be compile-time
constants.

--

---
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/?hl=en.



------=_Part_1019_4180909.1359423487451
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would edit my post, but mailing lists don't like that. :p<div><br></div><=
div>An alternative and more generic approach would be switch (begin : end),=
 which would work for everything where *begin is an integral type. The labe=
ls must have the type (*begin)[N] and of course be compile-time constants.<=
/div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1019_4180909.1359423487451--

.

------=_Part_3328_1772700608.1422960393281
Content-Type: multipart/alternative;
 boundary="----=_Part_3329_1738483825.1422960393281"

------=_Part_3329_1738483825.1422960393281
Content-Type: text/plain; charset=UTF-8

I would love a generic switch statement that goes even further than
strings: Any type that supports operator == shall be allowed within a
switch statement. The element for the case statement must be a constant:

std::string s;
switch(s)
{
    case "foo": ... break;
    case "bar": ... break;
    default: break;
}

The compiler produces a series of if-statements or is even allowed to build
a static map if the switch is huge.

Similar:

struct S
{
    S(int v) : val(v) {}
    bool operator == (const S &r) { return val == r.val; }
    int val;
};

static const S s(15);
static const S t(16);

S a(15);
switch(a)
{
    case s: ... break;
    case t: ... break;
    default: break;
}

which the compiler again can unroll into a series of switch statements.


Am Dienstag, 29. Januar 2013 02:38:07 UTC+1 schrieb cook...@gmail.com:
>
> I would edit my post, but mailing lists don't like that. :p
>
> An alternative and more generic approach would be switch (begin : end),
> which would work for everything where *begin is an integral type. The
> labels must have the type (*begin)[N] and of course be compile-time
> constants.
>

--

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

<div dir=3D"ltr">I would love a generic switch statement that goes even fur=
ther than strings: Any type that supports operator =3D=3D shall be allowed =
within a switch statement. The element for the case statement must be a con=
stant:<div><br></div><div>std::string s;</div><div>switch(s)</div><div>{</d=
iv><div>&nbsp; &nbsp; case "foo": ... break;</div><div>&nbsp; &nbsp; case "=
bar": ... break;<br></div><div>&nbsp; &nbsp; default: break;</div><div>}</d=
iv><div><br></div><div>The compiler produces a series of if-statements or i=
s even allowed to build a static map if the switch is huge.</div><div><br><=
/div><div>Similar:</div><div><br></div><div>struct S</div><div>{</div><div>=
&nbsp; &nbsp; S(int v) : val(v) {}</div><div>&nbsp; &nbsp; bool operator =
=3D=3D (const S &amp;r) { return val =3D=3D r.val; }</div><div>&nbsp; &nbsp=
; int val;</div><div>};</div><div><br></div><div>static const S s(15);</div=
><div>static const S t(16);</div><div><br></div><div>S a(15);</div><div>swi=
tch(a)</div><div>{</div><div>&nbsp; &nbsp; case s: ... break;</div><div>&nb=
sp; &nbsp; case t: ... break;</div><div>&nbsp; &nbsp; default: break;</div>=
<div>}</div><div><br></div><div>which the compiler again can unroll into a =
series of switch statements.</div><div><br><br>Am Dienstag, 29. Januar 2013=
 02:38:07 UTC+1 schrieb cook...@gmail.com:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">I would edit my post, but mailing lists don't like that. :p<div=
><br></div><div>An alternative and more generic approach would be switch (b=
egin : end), which would work for everything where *begin is an integral ty=
pe. The labels must have the type (*begin)[N] and of course be compile-time=
 constants.</div></blockquote></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_3329_1738483825.1422960393281--
------=_Part_3328_1772700608.1422960393281--

.

------=_Part_3376_1995134025.1422961207254
Content-Type: multipart/alternative;
 boundary="----=_Part_3377_1407893917.1422961207254"

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


On Tuesday, 3 February 2015 10:46:33 UTC, marco...@gmail.com wrote:=20
>
> I would love a generic switch statement that goes even further than=20
> strings: Any type that supports operator =3D=3D shall be allowed within a=
=20
> switch statement. The element for the case statement must be a constant:=
=20
>
> std::string s;
> switch(s)
> {
>     case "foo": ... break;
>     case "bar": ... break;
>     default: break;
> }
>
> The compiler produces a series of if-statements or is even allowed to=20
> build a static map if the switch is huge.
>
> Similar:
>
> struct S
> {
>     S(int v) : val(v) {}
>     bool operator =3D=3D (const S &r) { return val =3D=3D r.val; }
>     int val;
> };
>
> static const S s(15);
> static const S t(16);
>
> S a(15);
> switch(a)
> {
>     case s: ... break;
>     case t: ... break;
>     default: break;
> }
>
> which the compiler again can unroll into a series of switch statements.
>
> We could go even further, and allow arbitrary predicates (not just named=
=20
operator=3D=3D), for example,
=20
=20
 switch<foo> (bar) {=20
=20
case baz:=20
// ...=20
}

=20
checks foo(bar, baz).  I know this is somewhat whacky, but=E2=80=A6
=20

> =20
> Am Dienstag, 29. Januar 2013 02:38:07 UTC+1 schrieb cook...@gmail.com:=20
>>
>> I would edit my post, but mailing lists don't like that. :p=20
>>
>> An alternative and more generic approach would be switch (begin : end),=
=20
>> which would work for everything where *begin is an integral type. The=20
>> labels must have the type (*begin)[N] and of course be compile-time=20
>> constants.
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><BR>On Tuesday, 3 February 2015 10:46:33 UTC, marco...@gma=
il.com wrote:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>I would love a generic switch statement that goes even furth=
er than strings: Any type that supports operator =3D=3D shall be allowed wi=
thin a switch statement. The element for the case statement must be a const=
ant:=20
<DIV><BR></DIV>
<DIV>std::string s;</DIV>
<DIV>switch(s)</DIV>
<DIV>{</DIV>
<DIV>&nbsp; &nbsp; case "foo": ... break;</DIV>
<DIV>&nbsp; &nbsp; case "bar": ... break;<BR></DIV>
<DIV>&nbsp; &nbsp; default: break;</DIV>
<DIV>}</DIV>
<DIV><BR></DIV>
<DIV>The compiler produces a series of if-statements or is even allowed to =
build a static map if the switch is huge.</DIV>
<DIV><BR></DIV>
<DIV>Similar:</DIV>
<DIV><BR></DIV>
<DIV>struct S</DIV>
<DIV>{</DIV>
<DIV>&nbsp; &nbsp; S(int v) : val(v) {}</DIV>
<DIV>&nbsp; &nbsp; bool operator =3D=3D (const S &amp;r) { return val =3D=
=3D r.val; }</DIV>
<DIV>&nbsp; &nbsp; int val;</DIV>
<DIV>};</DIV>
<DIV><BR></DIV>
<DIV>static const S s(15);</DIV>
<DIV>static const S t(16);</DIV>
<DIV><BR></DIV>
<DIV>S a(15);</DIV>
<DIV>switch(a)</DIV>
<DIV>{</DIV>
<DIV>&nbsp; &nbsp; case s: ... break;</DIV>
<DIV>&nbsp; &nbsp; case t: ... break;</DIV>
<DIV>&nbsp; &nbsp; default: break;</DIV>
<DIV>}</DIV>
<DIV><BR></DIV>
<DIV>which the compiler again can unroll into a series of switch statements=
..</DIV>
<DIV><BR></DIV></DIV></BLOCKQUOTE>
<DIV>We could go even further, and allow arbitrary predicates (not just nam=
ed operator=3D=3D), for example,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>switch</SPAN><SPAN style=3D"COLOR: #080" class=3Dstyled-by-prettify=
>&lt;foo&gt;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> =
</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN=
 style=3D"COLOR: #000" class=3Dstyled-by-prettify>bar</SPAN><SPAN style=3D"=
COLOR: #660" class=3Dstyled-by-prettify>)</SPAN><SPAN style=3D"COLOR: #000"=
 class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dsty=
led-by-prettify>{</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prett=
ify>&nbsp;<BR>&nbsp;<BR></SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-b=
y-prettify>case</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettif=
y> baz</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>:</SPAN=
><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR></SPAN><S=
PAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// ...</SPAN><SPAN sty=
le=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR></SPAN><SPAN style=
=3D"COLOR: #660" class=3Dstyled-by-prettify>}</SPAN></DIV></CODE></DIV><BR>
<DIV>&nbsp;</DIV>
<DIV>checks foo(bar, baz).&nbsp; I know this is somewhat whacky, but=E2=80=
=A6</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV><BR>Am Dienstag, 29. Januar 2013 02:38:07 UTC+1 schrieb <A>cook...@gma=
il.com</A>:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>I would edit my post, but mailing =
lists don't like that. :p=20
<DIV><BR></DIV>
<DIV>An alternative and more generic approach would be switch (begin : end)=
, which would work for everything where *begin is an integral type. The lab=
els must have the type (*begin)[N] and of course be compile-time constants.=
</DIV></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE></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_3377_1407893917.1422961207254--
------=_Part_3376_1995134025.1422961207254--

.

On 3 February 2015 at 12:46,  <marconef24@gmail.com> wrote:
> I would love a generic switch statement that goes even further than strings:
> Any type that supports operator == shall be allowed within a switch
> statement. The element for the case statement must be a constant:
>
> std::string s;
> switch(s)
> {
>     case "foo": ... break;
>     case "bar": ... break;
>     default: break;
> }
>
> The compiler produces a series of if-statements or is even allowed to build
> a static map if the switch is huge.

It's possible to write such things as libraries without adding core
language facilities.
The syntax won't be identical to the built-in switch-case, and I
consider that a feature.
A *very* crude approximation that I wrote years ago and didn't bother
to make prettier
(I could use a type named 'Case' for the cases, I could allow
fall-through as an explicit
option...):
http://coliru.stacked-crooked.com/a/ee0176042f11b080

Now, we ask ourselves "what the huh? What's the point of that example? We don't
seriously expect every user to write that?" No, we don't expect every
user to write that.
The point is that lambdas allow creating new control structures, or
something very close
to that. Hence, before a language addition is considered, why not
consider a library
algorithm?

--

---
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_240_1476040204.1422961689144
Content-Type: multipart/alternative;
 boundary="----=_Part_241_76618484.1422961689144"

------=_Part_241_76618484.1422961689144
Content-Type: text/plain; charset=UTF-8


>
> It's possible to write such things as libraries without adding core
> language facilities.
> The syntax won't be identical to the built-in switch-case, and I
> consider that a feature.
>

But the syntax should be identical, that's what it is all about. Many
programmers that come from other languages are used to that kind of switch
statements. For them it would be easier to learn C++. And it also allows to
write prettier code, especially for the string case that is not so
uncommon. How often have you had to write a series of if(strcmp(...) == 0)
{ ... }?

--

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It's possible=
 to write such things as libraries without adding core
<br>language facilities.
<br>The syntax won't be identical to the built-in switch-case, and I
<br>consider that a feature.
<br></blockquote><div>&nbsp;</div><div>But the syntax should be identical, =
that's what it is all about. Many programmers that come from other language=
s are used to that kind of switch statements. For them it would be easier t=
o learn C++. And it also allows to write prettier code, especially for the =
string case that is not so uncommon. How often have you had to write a seri=
es of if(strcmp(...) =3D=3D 0) { ... }?</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_241_76618484.1422961689144--
------=_Part_240_1476040204.1422961689144--

.

On 3 February 2015 at 13:08,  <marconef24@gmail.com> wrote:
>> It's possible to write such things as libraries without adding core
>> language facilities.
>> The syntax won't be identical to the built-in switch-case, and I
>> consider that a feature.
>
>
> But the syntax should be identical, that's what it is all about. Many

I daresay I disagree with that general approach, see next.

> programmers that come from other languages are used to that kind of switch
> statements. For them it would be easier to learn C++. And it also allows to
> write prettier code, especially for the string case that is not so uncommon.
> How often have you had to write a series of if(strcmp(...) == 0) { ... }?

Fairly often. I don't mind doing that, since I know I'm not falling
into the traps
present in the existing switch. That's also one reason not to put more
stuff into
switch-case - it's not beneficial to guide people to use it more, since every
time it's used, one has to be careful about the problems it may have.

And no, we can't fix those problems, due to compatibility reasons. Such
ideas are dead on arrival.

--

---
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_308_488172137.1422964663770
Content-Type: multipart/alternative;
 boundary="----=_Part_309_1321575019.1422964663770"

------=_Part_309_1321575019.1422964663770
Content-Type: text/plain; charset=UTF-8

Am Dienstag, 3. Februar 2015 12:52:32 UTC+1 schrieb Ville Voutilainen:
>
> Fairly often. I don't mind doing that, since I know I'm not falling
> into the traps present in the existing switch. That's also one reason not
> to put more
> stuff into switch-case - it's not beneficial to guide people to use it
> more, since every
> time it's used, one has to be careful about the problems it may have.
>
> And no, we can't fix those problems, due to compatibility reasons. Such
> ideas are dead on arrival.
>

I don't understand:

   - What are the potential problems / traps? If this proposal were
   realized in the standard there would not be traps because a final text
   would clear all problems...
   - What compatibility reasons? This proposal does not influence existing
   code, it's a completely new feature attached to the existing and common
   known syntax of a simple switch statement.

--

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

<div dir=3D"ltr">Am Dienstag, 3. Februar 2015 12:52:32 UTC+1 schrieb Ville =
Voutilainen:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Fairly often. I do=
n't mind doing that, since I know I'm not falling
<br>into the traps
present in the existing switch. That's also one reason not to put more
<br>stuff into
switch-case - it's not beneficial to guide people to use it more, since eve=
ry
<br>time it's used, one has to be careful about the problems it may have.
<br>
<br>And no, we can't fix those problems, due to compatibility reasons. Such
<br>ideas are dead on arrival.
<br></blockquote><div><br></div><div>I don't understand:</div><div><ul><li>=
What are the potential problems / traps? If this proposal were realized in =
the standard there would not be traps because a final text would clear all =
problems...</li><li>What compatibility reasons? This proposal does not infl=
uence existing code, it's a completely new feature attached to the existing=
 and common known syntax of a simple switch statement.</li></ul></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_309_1321575019.1422964663770--
------=_Part_308_488172137.1422964663770--

.

On 3 February 2015 at 13:57,  <marconef24@gmail.com> wrote:
> Am Dienstag, 3. Februar 2015 12:52:32 UTC+1 schrieb Ville Voutilainen:
>>
>> Fairly often. I don't mind doing that, since I know I'm not falling
>> into the traps present in the existing switch. That's also one reason not
>> to put more
>> stuff into switch-case - it's not beneficial to guide people to use it
>> more, since every
>> time it's used, one has to be careful about the problems it may have.
>>
>> And no, we can't fix those problems, due to compatibility reasons. Such
>> ideas are dead on arrival.
>
>
> I don't understand:
>
> What are the potential problems / traps? If this proposal were realized in
> the standard there would not be traps because a final text would clear all
> problems...
> What compatibility reasons? This proposal does not influence existing code,
> it's a completely new feature attached to the existing and common known
> syntax of a simple switch statement.


switch-case does implicit fall-through and the cases are not mandated
to be blocks
in their own right. Those are its main problem, but since existing
code relies on both of them, it can't be changed. Adding new features to
the existing and not-so-well-understood not-at-all-simple switch statement
is counter-productive.

--

---
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_4793_1500890335.1422967636537
Content-Type: multipart/alternative;
 boundary="----=_Part_4794_1120942683.1422967636537"

------=_Part_4794_1120942683.1422967636537
Content-Type: text/plain; charset=UTF-8

Another approach to have strings in switch is to use `constexpr` hash
functions:


switch (hash(some_string))
{
case hash("test1"): foo(); break;
case hash("test2"): bar(); break;
case hash("aaa"):
//case hash("bbb"): error same hash like "aaa"
    if (some_string == "aaa") a1(); else b1();
    break;
}
Only problem its have is hash collision.



On Tuesday, February 3, 2015 at 12:00:52 PM UTC+1, Ville Voutilainen wrote:
>
> On 3 February 2015 at 12:46,  <marco...@gmail.com <javascript:>> wrote:
> > I would love a generic switch statement that goes even further than
> strings:
> > Any type that supports operator == shall be allowed within a switch
> > statement. The element for the case statement must be a constant:
> >
> > std::string s;
> > switch(s)
> > {
> >     case "foo": ... break;
> >     case "bar": ... break;
> >     default: break;
> > }
> >
> > The compiler produces a series of if-statements or is even allowed to
> build
> > a static map if the switch is huge.
>
> It's possible to write such things as libraries without adding core
> language facilities.
> The syntax won't be identical to the built-in switch-case, and I
> consider that a feature.
> A *very* crude approximation that I wrote years ago and didn't bother
> to make prettier
> (I could use a type named 'Case' for the cases, I could allow
> fall-through as an explicit
> option...):
> http://coliru.stacked-crooked.com/a/ee0176042f11b080
>
> Now, we ask ourselves "what the huh? What's the point of that example? We
> don't
> seriously expect every user to write that?" No, we don't expect every
> user to write that.
> The point is that lambdas allow creating new control structures, or
> something very close
> to that. Hence, before a language addition is considered, why not
> consider a library
> algorithm?
>

--

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

<div dir=3D"ltr">Another approach to have strings in switch is to use `cons=
texpr` hash functions:<br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">switch</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">hash</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">some_string</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> hash</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">"test1"</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>):</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> hash</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">"test2"</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">):</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> hash</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-=
prettify">"aaa"</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">):</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//case ha=
sh("bbb"): error same hash like "aaa"</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">some_string </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"a=
aa"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> a1</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">else</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> b1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">break</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div>Only problem its have is hash collision.<br><br>=
<br><br>On Tuesday, February 3, 2015 at 12:00:52 PM UTC+1, Ville Voutilaine=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3 February 2015 at =
12:46, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"UQ4MSoaTfw8J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">marc=
o...@gmail.com</a>&gt; wrote:
<br>&gt; I would love a generic switch statement that goes even further tha=
n strings:
<br>&gt; Any type that supports operator =3D=3D shall be allowed within a s=
witch
<br>&gt; statement. The element for the case statement must be a constant:
<br>&gt;
<br>&gt; std::string s;
<br>&gt; switch(s)
<br>&gt; {
<br>&gt; &nbsp; &nbsp; case "foo": ... break;
<br>&gt; &nbsp; &nbsp; case "bar": ... break;
<br>&gt; &nbsp; &nbsp; default: break;
<br>&gt; }
<br>&gt;
<br>&gt; The compiler produces a series of if-statements or is even allowed=
 to build
<br>&gt; a static map if the switch is huge.
<br>
<br>It's possible to write such things as libraries without adding core
<br>language facilities.
<br>The syntax won't be identical to the built-in switch-case, and I
<br>consider that a feature.
<br>A *very* crude approximation that I wrote years ago and didn't bother
<br>to make prettier
<br>(I could use a type named 'Case' for the cases, I could allow
<br>fall-through as an explicit
<br>option...):
<br><a href=3D"http://coliru.stacked-crooked.com/a/ee0176042f11b080" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fcoliru.stacked-crooked.com%2Fa%2Fee0176042f11b080\=
46sa\75D\46sntz\0751\46usg\75AFQjCNGFZSdMvBxdJb9sgqVILoii21V9nw';return tru=
e;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcoli=
ru.stacked-crooked.com%2Fa%2Fee0176042f11b080\46sa\75D\46sntz\0751\46usg\75=
AFQjCNGFZSdMvBxdJb9sgqVILoii21V9nw';return true;">http://coliru.stacked-cro=
oked.<wbr>com/a/ee0176042f11b080</a>
<br>
<br>Now, we ask ourselves "what the huh? What's the point of that example? =
We don't
<br>seriously expect every user to write that?" No, we don't expect every
<br>user to write that.
<br>The point is that lambdas allow creating new control structures, or
<br>something very close
<br>to that. Hence, before a language addition is considered, why not
<br>consider a library
<br>algorithm?
<br></blockquote></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_4794_1120942683.1422967636537--
------=_Part_4793_1500890335.1422967636537--

.

------=_Part_280_1500530792.1422968626542
Content-Type: multipart/alternative;
 boundary="----=_Part_281_1520554423.1422968626542"

------=_Part_281_1520554423.1422968626542
Content-Type: text/plain; charset=UTF-8

Am Dienstag, 3. Februar 2015 13:12:08 UTC+1 schrieb Ville Voutilainen:
>
> switch-case does implicit fall-through and the cases are not mandated
> to be blocks in their own right. Those are its main problem, but since
> existing
> code relies on both of them, it can't be changed. Adding new features to
> the existing and not-so-well-understood not-at-all-simple switch statement
> is counter-productive.
>

Every switch statement can be written by using if statements. If you use
goto (branches) that can be optimized. That's the compilers job. Implicit
fall-through is no problem here.

const char s[] = "...";
switch(s)
{
    case "bla":  doX();   // fall-through.
    case "ble":  doY();
                      break;
    case "bli":   doZ();
                      break;
    default:       break;
}

Stupid way:

if(strcmp(s, "bla") == 0) { doX(); doY(); }
else if(strcmp(s, "ble") == 0) { doY(); }
else if(strcmp(s, "bli") == 0) { doZ(); }

More towards assemly level (maybe what a compiler would translate it to):

if(strcmp(s, "bla") == 0) goto BLA;
if(strcmp(s, "ble") == 0) goto BLE;
if(strcmp(s, "bli") == 0) goto BLI;
goto END;
BLA:  doX(); goto BLE;
BLE:  doY(); goto END;
BLI:   doZ(); goto END;
END:

So again: Where are the compatibility problems? Where are the pitfalls?

The only problem I see is how does the compiler guarantee that all the
cases are different. If they are constants the compiler should be able to
check that condition.

--

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

<div dir=3D"ltr">Am Dienstag, 3. Februar 2015 13:12:08 UTC+1 schrieb Ville =
Voutilainen:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">switch-case does i=
mplicit fall-through and the cases are not mandated
<br>to be blocks
in their own right. Those are its main problem, but since existing
<br>code relies on both of them, it can't be changed. Adding new features t=
o
<br>the existing and not-so-well-understood not-at-all-simple switch statem=
ent
<br>is counter-productive.
<br></blockquote><div><br></div><div>Every switch statement can be written =
by using if statements. If you use goto (branches) that can be optimized. T=
hat's the compilers job. Implicit fall-through is no problem here.</div><di=
v><br></div><div>const char s[] =3D "...";</div><div>switch(s)</div><div>{<=
/div><div>&nbsp; &nbsp; case "bla": &nbsp;doX(); &nbsp; // fall-through.</d=
iv><div>&nbsp; &nbsp; case "ble": &nbsp;doY();</div><div>&nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; break;</div><div=
>&nbsp; &nbsp; case "bli": &nbsp; doZ();</div><div>&nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; break;</div><div>&nbsp=
; &nbsp; default: &nbsp; &nbsp; &nbsp; break;</div><div>}</div><div><br></d=
iv><div>Stupid way:</div><div><br></div><div>if(strcmp(s, "bla") =3D=3D 0) =
{ doX(); doY(); }</div><div>else if(strcmp(s, "ble") =3D=3D 0) { doY(); }</=
div><div>else if(strcmp(s, "bli") =3D=3D 0) { doZ(); }</div><div><br></div>=
<div>More towards assemly level (maybe what a compiler would translate it t=
o):</div><div><br></div><div>if(strcmp(s, "bla") =3D=3D 0) goto BLA;</div><=
div>if(strcmp(s, "ble") =3D=3D 0) goto BLE;<br></div><div>if(strcmp(s, "bli=
") =3D=3D 0) goto BLI;<br></div><div>goto END;</div><div>BLA: &nbsp;doX(); =
goto BLE;</div><div>BLE: &nbsp;doY(); goto END;</div><div>BLI: &nbsp; doZ()=
; goto END;</div><div>END:</div><div><br></div><div>So again: Where are the=
 compatibility problems? Where are the pitfalls?</div><div><br></div><div>T=
he only problem I see is how does the compiler guarantee that all the cases=
 are different. If they are constants the compiler should be able to check =
that condition.</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_281_1520554423.1422968626542--
------=_Part_280_1500530792.1422968626542--

.

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

I think there is a mismatch in the communication. Ville's issues with
'switch' are not regarding this proposal, but with the existing 'switch'.
The existing 'switch' cannot be changed to amend those issues as that would
break existing programs that depend on it.  If you buy into 'switch' being
a "somehow" broken construct, then adding more usages to it would be going
the wrong way.

Personally I am not sure that there would be an advantage to this approach.
Sure, the syntax could be a bit more like python's and if you come from
that context you might be inclined to do that switch.  But if you cannot do
a switch you might end up doing something more creative. For example, the
'hash' that was mentioned before: use gperf to generate a perfect hash for
your literals, then encode with a switch and a check... some more manual
work, but at the same time a better solution than testing one by one all
strings --you could also build on gperf to write the 'switch' equivalent
for you, that is to generate the enum and test the argument against the
values.  We have a code generator that given the set of literals constructs
an efficient test mechanism that will generate an enum value for a string
(a decision tree) and then switch on the generated enum.

There are different solutions for this problem that are more efficient.
Yes, they are not as simple as typing 'switch', but 'switch' comes with
it's own baggage --default fallthrough, jump over initialization of
variables... -- that make it non-novice friendly anyway.

    David
On Tue Feb 03 2015 at 8:03:47 AM <marconef24@gmail.com> wrote:

> Am Dienstag, 3. Februar 2015 13:12:08 UTC+1 schrieb Ville Voutilainen:
>
>> switch-case does implicit fall-through and the cases are not mandated
>> to be blocks in their own right. Those are its main problem, but since
>> existing
>> code relies on both of them, it can't be changed. Adding new features to
>> the existing and not-so-well-understood not-at-all-simple switch
>> statement
>> is counter-productive.
>>
>
> Every switch statement can be written by using if statements. If you use
> goto (branches) that can be optimized. That's the compilers job. Implicit
> fall-through is no problem here.
>
> const char s[] = "...";
> switch(s)
> {
>     case "bla":  doX();   // fall-through.
>     case "ble":  doY();
>                       break;
>     case "bli":   doZ();
>                       break;
>     default:       break;
> }
>
> Stupid way:
>
> if(strcmp(s, "bla") == 0) { doX(); doY(); }
> else if(strcmp(s, "ble") == 0) { doY(); }
> else if(strcmp(s, "bli") == 0) { doZ(); }
>
> More towards assemly level (maybe what a compiler would translate it to):
>
> if(strcmp(s, "bla") == 0) goto BLA;
> if(strcmp(s, "ble") == 0) goto BLE;
> if(strcmp(s, "bli") == 0) goto BLI;
> goto END;
> BLA:  doX(); goto BLE;
> BLE:  doY(); goto END;
> BLI:   doZ(); goto END;
> END:
>
> So again: Where are the compatibility problems? Where are the pitfalls?
>
> The only problem I see is how does the compiler guarantee that all the
> cases are different. If they are constants the compiler should be able to
> check that condition.
>
> --
>
> ---
> 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/.

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

I think there is a mismatch in the communication. Ville&#39;s issues with &=
#39;switch&#39; are not regarding this proposal, but with the existing &#39=
;switch&#39;. The existing &#39;switch&#39; cannot be changed to amend thos=
e issues as that would break existing programs that depend on it.=C2=A0 If =
you buy into &#39;switch&#39; being a &quot;somehow&quot; broken construct,=
 then adding more usages to it would be going the wrong way.<br><br>Persona=
lly I am not sure that there would be an advantage to this approach. Sure, =
the syntax could be a bit more like python&#39;s and if you come from that =
context you might be inclined to do that switch.=C2=A0 But if you cannot do=
 a switch you might end up doing something more creative. For example, the =
&#39;hash&#39; that was mentioned before: use gperf to generate a perfect h=
ash for your literals, then encode with a switch and a check... some more m=
anual work, but at the same time a better solution than testing one by one =
all strings --you could also build on gperf to write the &#39;switch&#39; e=
quivalent for you, that is to generate the enum and test the argument again=
st the values.=C2=A0 We=C2=A0have a code generator that given the set of li=
terals constructs an efficient test mechanism that will generate an enum va=
lue for a string (a decision tree) and then switch on the generated enum.<b=
r><br>There are different solutions for this problem that are more efficien=
t. Yes, they are not as simple as typing &#39;switch&#39;, but &#39;switch&=
#39; comes with it&#39;s own baggage --default fallthrough, jump over initi=
alization of variables... -- that make it non-novice friendly anyway.<br><b=
r>=C2=A0 =C2=A0 David<br><div class=3D"gmail_quote">On Tue Feb 03 2015 at 8=
:03:47 AM &lt;<a href=3D"mailto:marconef24@gmail.com">marconef24@gmail.com<=
/a>&gt; 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">Am Dienst=
ag, 3. Februar 2015 13:12:08 UTC+1 schrieb Ville Voutilainen:</div><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">switch-case does implicit =
fall-through and the cases are not mandated
<br>to be blocks
in their own right. Those are its main problem, but since existing
<br>code relies on both of them, it can&#39;t be changed. Adding new featur=
es to
<br>the existing and not-so-well-understood not-at-all-simple switch statem=
ent
<br>is counter-productive.
<br></blockquote><div><br></div></div><div dir=3D"ltr"><div>Every switch st=
atement can be written by using if statements. If you use goto (branches) t=
hat can be optimized. That&#39;s the compilers job. Implicit fall-through i=
s no problem here.</div><div><br></div><div>const char s[] =3D &quot;...&qu=
ot;;</div><div>switch(s)</div><div>{</div><div>=C2=A0 =C2=A0 case &quot;bla=
&quot;: =C2=A0doX(); =C2=A0 // fall-through.</div><div>=C2=A0 =C2=A0 case &=
quot;ble&quot;: =C2=A0doY();</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=A0 ca=
se &quot;bli&quot;: =C2=A0 doZ();</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;</div><div>=C2=A0 =C2=
=A0 default: =C2=A0 =C2=A0 =C2=A0 break;</div><div>}</div><div><br></div><d=
iv>Stupid way:</div><div><br></div><div>if(strcmp(s, &quot;bla&quot;) =3D=
=3D 0) { doX(); doY(); }</div><div>else if(strcmp(s, &quot;ble&quot;) =3D=
=3D 0) { doY(); }</div><div>else if(strcmp(s, &quot;bli&quot;) =3D=3D 0) { =
doZ(); }</div><div><br></div><div>More towards assemly level (maybe what a =
compiler would translate it to):</div><div><br></div><div>if(strcmp(s, &quo=
t;bla&quot;) =3D=3D 0) goto BLA;</div><div>if(strcmp(s, &quot;ble&quot;) =
=3D=3D 0) goto BLE;<br></div><div>if(strcmp(s, &quot;bli&quot;) =3D=3D 0) g=
oto BLI;<br></div><div>goto END;</div><div>BLA: =C2=A0doX(); goto BLE;</div=
><div>BLE: =C2=A0doY(); goto END;</div><div>BLI: =C2=A0 doZ(); goto END;</d=
iv><div>END:</div><div><br></div><div>So again: Where are the compatibility=
 problems? Where are the pitfalls?</div><div><br></div><div>The only proble=
m I see is how does the compiler guarantee that all the cases are different=
.. If they are constants the compiler should be able to check that condition=
..</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" 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>
</blockquote></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 />

--001a11c13e26b1593b050e2f4ba0--

.

------=_Part_3565_7375977.1422971903670
Content-Type: multipart/alternative;
 boundary="----=_Part_3566_1561477560.1422971903670"

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


Am Dienstag, 3. Februar 2015 14:46:21 UTC+1 schrieb David Rodr=C3=ADguez Ib=
eas:
>
> I think there is a mismatch in the communication. Ville's issues with=20
> 'switch' are not regarding this proposal, but with the existing 'switch'.=
=20
> The existing 'switch' cannot be changed to amend those issues as that wou=
ld=20
> break existing programs that depend on it.  If you buy into 'switch' bein=
g=20
> a "somehow" broken construct, then adding more usages to it would be goin=
g=20
> the wrong way.
>

Maybe you're right. I don't want to change the behaviour of the current=20
switch statement. Actually I think it is very powerful and should behave as=
=20
it does. We never had programmers in our company who had problems with that=
=20
syntax.=20
=20

> ...
> There are different solutions for this problem that are more efficient.=
=20
> Yes, they are not as simple as typing 'switch', but 'switch' comes with=
=20
> it's own baggage --default fallthrough, jump over initialization of=20
> variables... -- that make it non-novice friendly anyway.


When proposing a change I don't think about performance. That is the=20
compilers job. It could create hash tables if it decides that it's a good=
=20
idea. Or anything else.

My point is that a switch statement taking strings would be very easy to=20
read to the programmer. That means it is less error prone than any other=20
solution, especially generating hash values outside and inserting these=20
numbers out of context in the code. Think about changes that may have to be=
=20
done to that code. The very same tool has to be used for the generation of=
=20
new hash values.

Code that is easy to read and still very powerful is easy for novices and=
=20
oldies, my opinion.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br>Am Dienstag, 3. Februar 2015 14:46:21 UTC+1 schrieb Da=
vid Rodr=C3=ADguez Ibeas:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I thi=
nk there is a mismatch in the communication. Ville's issues with 'switch' a=
re not regarding this proposal, but with the existing 'switch'. The existin=
g 'switch' cannot be changed to amend those issues as that would break exis=
ting programs that depend on it.&nbsp; If you buy into 'switch' being a "so=
mehow" broken construct, then adding more usages to it would be going the w=
rong way.<br></blockquote><div><br></div><div>Maybe you're right. I don't w=
ant to change the behaviour of the current switch statement. Actually I thi=
nk it is very powerful and should behave as it does. We never had programme=
rs in our company who had problems with that syntax.&nbsp;</div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">...<br>There are differe=
nt solutions for this problem that are more efficient. Yes, they are not as=
 simple as typing 'switch', but 'switch' comes with it's own baggage --defa=
ult fallthrough, jump over initialization of variables... -- that make it n=
on-novice friendly anyway.</blockquote><div><br></div><div>When proposing a=
 change I don't think about performance. That is the compilers job. It coul=
d create hash tables if it decides that it's a good idea. Or anything else.=
</div><div><br></div><div>My point is that a switch statement taking string=
s would be very easy to read to the programmer. That means it is less error=
 prone than any other solution, especially generating hash values outside a=
nd inserting these numbers out of context in the code. Think about changes =
that may have to be done to that code. The very same tool has to be used fo=
r the generation of new hash values.</div><div><br></div><div>Code that is =
easy to read and still very powerful is easy for novices and oldies, my opi=
nion.</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_3566_1561477560.1422971903670--
------=_Part_3565_7375977.1422971903670--

.

On 3 February 2015 at 15:58,  <marconef24@gmail.com> wrote:
> My point is that a switch statement taking strings would be very easy to
> read to the programmer. That means it is less error prone than any other
> solution, especially generating hash values outside and inserting these
> numbers out of context in the code. Think about changes that may have to be
> done to that code. The very same tool has to be used for the generation of
> new hash values.
> Code that is easy to read and still very powerful is easy for novices and
> oldies, my opinion.


How about the code presented in this paper?
http://www.stroustrup.com/OpenPatternMatching.pdf
As far as I understand, it can "switch" (aka Match) on both types and value.

--

---
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_0_1099953270.1422975597047
Content-Type: multipart/alternative;
 boundary="----=_Part_1_280955771.1422975597051"

------=_Part_1_280955771.1422975597051
Content-Type: text/plain; charset=UTF-8

Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilainen:
>
> How about the code presented in this paper?
> http://www.stroustrup.com/OpenPatternMatching.pdf
> As far as I understand, it can "switch" (aka Match) on both types and
> value.
>

Interesting paper, but still does not fulfill my request.

--

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

<div dir=3D"ltr">Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville =
Voutilainen:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">How about the code=
 presented in this paper?
<br><a href=3D"http://www.stroustrup.com/OpenPatternMatching.pdf" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com=
/url?q\75http%3A%2F%2Fwww.stroustrup.com%2FOpenPatternMatching.pdf\46sa\75D=
\46sntz\0751\46usg\75AFQjCNEd9hYt3ApfXyQHGz5D1GJM6EjtUA';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stroustr=
up.com%2FOpenPatternMatching.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEd9hYt3=
ApfXyQHGz5D1GJM6EjtUA';return true;">http://www.stroustrup.com/<wbr>OpenPat=
ternMatching.pdf</a>
<br>As far as I understand, it can "switch" (aka Match) on both types and v=
alue.
<br></blockquote><div><br></div><div>Interesting paper, but still does not =
fulfill my request.&nbsp;</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_1_280955771.1422975597051--
------=_Part_0_1099953270.1422975597047--

.

On 3 February 2015 at 16:59,  <marconef24@gmail.com> wrote:
> Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilainen:
>>
>> How about the code presented in this paper?
>> http://www.stroustrup.com/OpenPatternMatching.pdf
>> As far as I understand, it can "switch" (aka Match) on both types and
>> value.
> Interesting paper, but still does not fulfill my request.


Well, if by your request you mean enhancing switch to support strings,
there is a previous proposal
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html

Whether that will be accepted remains to be seen. I have some doubts
that it would, so there's a very good chance that your request will remain
unfulfilled.

--

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

.

On Tue, Feb 3, 2015 at 9:59 AM,  <marconef24@gmail.com> wrote:
> Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilainen:
>>
>> How about the code presented in this paper?
>> http://www.stroustrup.com/OpenPatternMatching.pdf
>> As far as I understand, it can "switch" (aka Match) on both types and
>> value.
>
>
> Interesting paper, but still does not fulfill my request.
>

Which part?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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_781_163726794.1422995161659
Content-Type: multipart/alternative;
 boundary="----=_Part_782_829674951.1422995161659"

------=_Part_782_829674951.1422995161659
Content-Type: text/plain; charset=UTF-8



Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhihao Yuan:
>
> On Tue, Feb 3, 2015 at 9:59 AM,  <marco...@gmail.com <javascript:>>
> wrote:
> > Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilainen:
> >>
> >> http://www.stroustrup.com/OpenPatternMatching.pdf
> >
> > Interesting paper, but still does not fulfill my request.
>
> Which part?
>

You mean which part of my request is not fulfilled? It is a proposal for a
very new approach. The code shown in the paper is very complicated if you
have to write it, that's stuff for long time C++ professionals. I would
much prefer if the well known switch statement were extended the way
described above.

--

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

<div dir=3D"ltr"><br><br>Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrie=
b Zhihao Yuan:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Feb 3, 2=
015 at 9:59 AM, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"DM-0GT9FtjIJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">marco...@gmail.com</a>&gt; wrote:
<br>&gt; Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilai=
nen:
<br>&gt;&gt;
<br>&gt;&gt; <a href=3D"http://www.stroustrup.com/OpenPatternMatching.pdf" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.stroustrup.com%2FOpenPatternMatching.pdf=
\46sa\75D\46sntz\0751\46usg\75AFQjCNEd9hYt3ApfXyQHGz5D1GJM6EjtUA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww=
..stroustrup.com%2FOpenPatternMatching.pdf\46sa\75D\46sntz\0751\46usg\75AFQj=
CNEd9hYt3ApfXyQHGz5D1GJM6EjtUA';return true;">http://www.stroustrup.com/<wb=
r>OpenPatternMatching.pdf</a>
<br>&gt;
<br>&gt; Interesting paper, but still does not fulfill my request.
<br><br>Which part?
<br></blockquote><div><br></div><div>You mean which part of my request is n=
ot fulfilled? It is a proposal for a very new approach. The code shown in t=
he paper is very complicated if you have to write it, that's stuff for long=
 time C++ professionals. I would much prefer if the well known switch state=
ment were extended the way described above.</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_782_829674951.1422995161659--
------=_Part_781_163726794.1422995161659--

.

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

On Tue, Feb 3, 2015 at 3:26 PM, <marconef24@gmail.com> wrote:

>
>
> Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhihao Yuan:
>>
>> On Tue, Feb 3, 2015 at 9:59 AM,  <marco...@gmail.com> wrote:
>> > Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilainen:
>> >>
>> >> http://www.stroustrup.com/OpenPatternMatching.pdf
>> >
>> > Interesting paper, but still does not fulfill my request.
>>
>> Which part?
>>
>
> You mean which part of my request is not fulfilled? It is a proposal for a
> very new approach. The code shown in the paper is very complicated if you
> have to write it, that's stuff for long time C++ professionals. I would
> much prefer if the well known switch statement were extended the way
> described above.
>
> --
>

The paper is a bit hard to understand.  But Stroustrup gave a presentation
to the committee of a 'inspect' keyword, which was based on the paper, that
did everything you wanted and more.
And fixed switch's other age-old problems while he was at it.

Tony

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Feb 3, 2015 at 3:26 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:marconef24@gmail.com" target=3D"_blank">marconef24@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Am Die=
nstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhihao Yuan:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D"">On Tue, Feb 3, 2015 at 9:59 AM, =C2=
=A0&lt;<a rel=3D"nofollow">marco...@gmail.com</a>&gt; wrote:
<br>&gt; Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilai=
nen:
<br>&gt;&gt;
<br></span>&gt;&gt; <a href=3D"http://www.stroustrup.com/OpenPatternMatchin=
g.pdf" rel=3D"nofollow" target=3D"_blank">http://www.stroustrup.com/<u></u>=
OpenPatternMatching.pdf</a>
<br><span class=3D"">&gt;
<br>&gt; Interesting paper, but still does not fulfill my request.
<br><br>Which part?
<br></span></blockquote><div><br></div><div>You mean which part of my reque=
st is not fulfilled? It is a proposal for a very new approach. The code sho=
wn in the paper is very complicated if you have to write it, that&#39;s stu=
ff for long time C++ professionals. I would much prefer if the well known s=
witch statement were extended the way described above.</div></div><div clas=
s=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br></div></div></blockquote><div><br></div></div>The paper is a bit har=
d to understand.=C2=A0 But Stroustrup gave a presentation to the committee =
of a &#39;inspect&#39; keyword, which was based on the paper, that did ever=
ything you wanted and more.<br>And fixed switch&#39;s other age-old problem=
s while he was at it.<br><br></div><div class=3D"gmail_extra">Tony<br></div=
></div>

<p></p>

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

--089e0160b7dae6e0e3050e352ac1--

.

------=_Part_280_298081141.1422998126064
Content-Type: multipart/alternative;
 boundary="----=_Part_281_1917871983.1422998126064"

------=_Part_281_1917871983.1422998126064
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 4, 2015 at 9:46:41 AM UTC+13, Tony V E wrote:
>
>
>
> On Tue, Feb 3, 2015 at 3:26 PM, <marco...@gmail.com <javascript:>> wrote:
>
>>
>>
>> Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhihao Yuan:
>>>
>>> On Tue, Feb 3, 2015 at 9:59 AM,  <marco...@gmail.com> wrote:
>>> > Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilainen:
>>> >>
>>> >> http://www.stroustrup.com/OpenPatternMatching.pdf
>>> >
>>> > Interesting paper, but still does not fulfill my request.
>>>
>>> Which part?
>>>
>>
>> You mean which part of my request is not fulfilled? It is a proposal for
>> a very new approach. The code shown in the paper is very complicated if you
>> have to write it, that's stuff for long time C++ professionals. I would
>> much prefer if the well known switch statement were extended the way
>> described above.
>>
>> --
>>
>
> The paper is a bit hard to understand.  But Stroustrup gave a presentation
> to the committee of a 'inspect' keyword, which was based on the paper, that
> did everything you wanted and more.
> And fixed switch's other age-old problems while he was at it.
>
> Tony
>

How very Interesting. Can you elaborate any more on how the
presentation differed from the paper and give an example of the proposed
inspect syntax?

--

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

<div dir=3D"ltr"><br><br>On Wednesday, February 4, 2015 at 9:46:41 AM UTC+1=
3, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><div><b=
r><div class=3D"gmail_quote">On Tue, Feb 3, 2015 at 3:26 PM,  <span dir=3D"=
ltr">&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"CCmqZkTuB-AJ">marco...@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"l=
tr"><br><br>Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhihao Yuan=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><span>On Tue, Feb 3, 2015 at 9:59 AM, &nbsp;&=
lt;<a rel=3D"nofollow">marco...@gmail.com</a>&gt; wrote:
<br>&gt; Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilai=
nen:
<br>&gt;&gt;
<br></span>&gt;&gt; <a onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\75http%3A%2F%2Fwww.stroustrup.com%2FOpenPatternMatching.pdf\46sa\75D\46=
sntz\0751\46usg\75AFQjCNEd9hYt3ApfXyQHGz5D1GJM6EjtUA';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stroustrup.=
com%2FOpenPatternMatching.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNEd9hYt3Apf=
XyQHGz5D1GJM6EjtUA';return true;" href=3D"http://www.stroustrup.com/OpenPat=
ternMatching.pdf" target=3D"_blank" rel=3D"nofollow">http://www.stroustrup.=
com/<u></u>Open<wbr>PatternMatching.pdf</a>
<br><span>&gt;
<br>&gt; Interesting paper, but still does not fulfill my request.
<br><br>Which part?
<br></span></blockquote><div><br></div><div>You mean which part of my reque=
st is not fulfilled? It is a proposal for a very new approach. The code sho=
wn in the paper is very complicated if you have to write it, that's stuff f=
or long time C++ professionals. I would much prefer if the well known switc=
h statement were extended the way described above.</div></div><div><div>

<p></p>

-- <br></div></div></blockquote><div><br></div></div>The paper is a bit har=
d to understand.&nbsp; But Stroustrup gave a presentation to the committee =
of a 'inspect' keyword, which was based on the paper, that did everything y=
ou wanted and more.<br>And fixed switch's other age-old problems while he w=
as at it.<br><br></div><div>Tony<br></div></div></blockquote><div><br></div=
><div>How very Interesting. Can you elaborate any more on&nbsp;how the pres=
entation&nbsp;differed from the paper&nbsp;and give an example of the propo=
sed inspect syntax?</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_281_1917871983.1422998126064--
------=_Part_280_298081141.1422998126064--

.

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

On Tue, Feb 3, 2015 at 4:15 PM, <gmisocpp@gmail.com> wrote:

>
>
> On Wednesday, February 4, 2015 at 9:46:41 AM UTC+13, Tony V E wrote:
>
>>
>>
>> On Tue, Feb 3, 2015 at 3:26 PM, <marco...@gmail.com> wrote:
>>
>>>
>>>
>>> Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhihao Yuan:
>>>>
>>>> On Tue, Feb 3, 2015 at 9:59 AM,  <marco...@gmail.com> wrote:
>>>> > Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville
>>>> Voutilainen:
>>>> >>
>>>> >> http://www.stroustrup.com/OpenPatternMatching.pdf
>>>> >
>>>> > Interesting paper, but still does not fulfill my request.
>>>>
>>>> Which part?
>>>>
>>>
>>> You mean which part of my request is not fulfilled? It is a proposal for
>>> a very new approach. The code shown in the paper is very complicated if you
>>> have to write it, that's stuff for long time C++ professionals. I would
>>> much prefer if the well known switch statement were extended the way
>>> described above.
>>>
>>> --
>>>
>>
>> The paper is a bit hard to understand.  But Stroustrup gave a
>> presentation to the committee of a 'inspect' keyword, which was based on
>> the paper, that did everything you wanted and more.
>> And fixed switch's other age-old problems while he was at it.
>>
>> Tony
>>
>
> How very Interesting. Can you elaborate any more on how the
> presentation differed from the paper and give an example of the proposed
> inspect syntax?
>
> --
>

The main difference was that it had readable examples :-)
I don't think he has published the slides, and I can't remember them enough
to do them justice by trying to make up an example.  But I do recall that
you could switch on types (ie switch on the current type in a variant<int,
double, string> ) as well as switch on values.  And actually cases where
you were doing matches on both within a single switch, IIRC.

Tony


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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Feb 3, 2015 at 4:15 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesd=
ay, February 4, 2015 at 9:46:41 AM UTC+13, Tony V E wrote:<div><div class=
=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid"><div dir=3D"ltr"><br><div><br><div class=3D"gmail_=
quote">On Tue, Feb 3, 2015 at 3:26 PM,  <span dir=3D"ltr">&lt;<a rel=3D"nof=
ollow">marco...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-co=
lor:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div di=
r=3D"ltr"><br><br>Am Dienstag, 3. Februar 2015 17:19:07 UTC+1 schrieb Zhiha=
o Yuan:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid"><span>On Tue, Feb 3, 2015 at 9:59 AM, =C2=A0&lt;<a =
rel=3D"nofollow">marco...@gmail.com</a>&gt; wrote:
<br>&gt; Am Dienstag, 3. Februar 2015 15:27:23 UTC+1 schrieb Ville Voutilai=
nen:
<br>&gt;&gt;
<br></span>&gt;&gt; <a href=3D"http://www.stroustrup.com/OpenPatternMatchin=
g.pdf" rel=3D"nofollow" target=3D"_blank">http://www.stroustrup.com/<u></u>=
Open<u></u>PatternMatching.pdf</a>
<br><span>&gt;
<br>&gt; Interesting paper, but still does not fulfill my request.
<br><br>Which part?
<br></span></blockquote><div><br></div><div>You mean which part of my reque=
st is not fulfilled? It is a proposal for a very new approach. The code sho=
wn in the paper is very complicated if you have to write it, that&#39;s stu=
ff for long time C++ professionals. I would much prefer if the well known s=
witch statement were extended the way described above.</div></div><div><div=
>

<p></p>

-- <br></div></div></blockquote><div><br></div></div>The paper is a bit har=
d to understand.=C2=A0 But Stroustrup gave a presentation to the committee =
of a &#39;inspect&#39; keyword, which was based on the paper, that did ever=
ything you wanted and more.<br>And fixed switch&#39;s other age-old problem=
s while he was at it.<br><br></div><div>Tony<br></div></div></blockquote><d=
iv><br></div></div></div><div>How very Interesting. Can you elaborate any m=
ore on=C2=A0how the presentation=C2=A0differed from the paper=C2=A0and give=
 an example of the proposed inspect syntax?</div></div><div class=3D"HOEnZb=
"><div class=3D"h5">

<p></p>

-- <br></div></div></blockquote><div><br></div><div>The main difference was=
 that it had readable examples :-)<br></div><div>I don&#39;t think he has p=
ublished the slides, and I can&#39;t remember them enough to do them justic=
e by trying to make up an example.=C2=A0 But I do recall that you could swi=
tch on types (ie switch on the current type in a variant&lt;int, double, st=
ring&gt; ) as well as switch on values.=C2=A0 And actually cases where you =
were doing matches on both within a single switch, IIRC.<br><br></div><div>=
Tony<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"H=
OEnZb"><div class=3D"h5">
<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></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 />

--001a11c32cf4bbf0c9050e35ea47--

.

------=_Part_426_19089443.1423009986007
Content-Type: multipart/alternative;
 boundary="----=_Part_427_861205098.1423009986007"

------=_Part_427_861205098.1423009986007
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 4, 2015 at 10:40:20 AM UTC+13, Tony V E wrote:
>
> The main difference was that it had readable examples :-)
> I don't think he has published the slides, and I can't remember them
> enough to do them justice by trying to make up an example.  But I do recall
> that you could switch on types (ie switch on the current type in a
> variant<int, double, string> ) as well as switch on values.  And actually
> cases where you were doing matches on both within a single switch, IIRC.
>
> Tony
>

ok. Sounds pretty tantalizing. I hope Bjarne is watching and decides to
share more. Can't wait.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, February 4, 2015 at 10:40:20 AM UTC+=
13, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div>The main difference was that it had readable exa=
mples :-)<br></div><div>I don't think he has published the slides, and I ca=
n't remember them enough to do them justice by trying to make up an example=
..&nbsp; But I do recall that you could switch on types (ie switch on the cu=
rrent type in a variant&lt;int, double, string&gt; ) as well as switch on v=
alues.&nbsp; And actually cases where you were doing matches on both within=
 a single switch, IIRC.<br><br></div><div>Tony<br></div></div></div></div><=
/blockquote><div><br></div><div>ok. Sounds pretty tantalizing.&nbsp;I hope =
Bjarne&nbsp;is watching and decides&nbsp;to share more. Can't wait.</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_427_861205098.1423009986007--
------=_Part_426_19089443.1423009986007--

.

--Apple-Mail=_241DB0A0-ED84-46A9-A862-72668AD14436
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9303, at 9:46 PM, David Rodr=C3=ADguez Ibeas <di=
beas@ieee.org> wrote:
>=20
> I think there is a mismatch in the communication. Ville's issues with 'sw=
itch' are not regarding this proposal, but with the existing 'switch'. The =
existing 'switch' cannot be changed to amend those issues as that would bre=
ak existing programs that depend on it.  If you buy into 'switch' being a "=
somehow" broken construct, then adding more usages to it would be going the=
 wrong way.

If you buy into switch with fallthrough being not broken, then adding new u=
sages without fallthrough is still going the wrong way.

I don=E2=80=99t see the point in encouraging folks to continue using switch=
, just because it=E2=80=99s their habit, especially when switching language=
s. If you want if-else semantics, write if-else. Optimization is the compil=
er=E2=80=99s job and it=E2=80=99s a little presumptuous to say that it won=
=E2=80=99t optimize an if-else strcmp chain. Strcmp is a pure function. Ena=
ble profile-guided optimization and see what happens.

Bjarne=E2=80=99s mechanism is pretty cool, but note that it includes its ow=
n caching scheme which might be better or worse than CPU branch prediction.=
 Measure carefully.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_241DB0A0-ED84-46A9-A862-72668AD14436
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9303, at 9:46 PM, David Rodr=C3=ADguez Ibeas &lt;<a href=3D"mailto:d=
ibeas@ieee.org" class=3D"">dibeas@ieee.org</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D"">I think there is a mismatch in =
the communication. Ville's issues with 'switch' are not regarding this prop=
osal, but with the existing 'switch'. The existing 'switch' cannot be chang=
ed to amend those issues as that would break existing programs that depend =
on it.&nbsp; If you buy into 'switch' being a "somehow" broken construct, t=
hen adding more usages to it would be going the wrong way.<br class=3D""></=
div></blockquote><div><br class=3D""></div><div>If you buy into switch with=
 fallthrough being <i class=3D"">not</i>&nbsp;broken, then adding new usage=
s without fallthrough is still going the wrong way.</div><div><br class=3D"=
"></div><div>I don=E2=80=99t see the point in encouraging folks to continue=
 using switch, just because it=E2=80=99s their habit, especially when switc=
hing languages. If you want if-else semantics, write if-else. Optimization =
is the compiler=E2=80=99s job and it=E2=80=99s a little presumptuous to say=
 that it won=E2=80=99t optimize an if-else strcmp chain. Strcmp is a pure f=
unction. Enable profile-guided optimization and see what happens.</div><div=
><br class=3D""></div><div>Bjarne=E2=80=99s mechanism is pretty cool, but n=
ote that it includes its own caching scheme which might be better or worse =
than CPU branch prediction. Measure carefully.</div></div></body></html>

<p></p>

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

--Apple-Mail=_241DB0A0-ED84-46A9-A862-72668AD14436--

.

------=_Part_519_186817757.1423031113186
Content-Type: multipart/alternative;
 boundary="----=_Part_520_224949985.1423031113186"

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


Am Mittwoch, 4. Februar 2015 01:47:28 UTC+1 schrieb David Krauss:
>
>
> If you buy into switch with fallthrough being *not* broken, then adding=
=20
> new usages without fallthrough is still going the wrong way.
>
> I don=E2=80=99t see the point in encouraging folks to continue using swit=
ch, just=20
> because it=E2=80=99s their habit, especially when switching languages. If=
 you want=20
> if-else semantics, write if-else. Optimization is the compiler=E2=80=99s =
job and=20
> it=E2=80=99s a little presumptuous to say that it won=E2=80=99t optimize =
an if-else strcmp=20
> chain. Strcmp is a pure function. Enable profile-guided optimization and=
=20
> see what happens.
>
> Bjarne=E2=80=99s mechanism is pretty cool, but note that it includes its =
own=20
> caching scheme which might be better or worse than CPU branch prediction.=
=20
> Measure carefully.
>

Who wants to add new usages *without* fallthrough? That would really be a=
=20
very bad idea. No, the proposal was extended usages for the switch=20
statement, keeping its behaviour. See my example above.

Sure, we could write that by a series of if / if else statements with the=
=20
very same result. But readability is very poor in comparison to the=20
proposal. Good readability leads to good / stable software. If C++ code=20
leads to good / stable software more people start using this fabulous=20
language again. I can remember Herb Suter saying that this was one of the=
=20
ideas behind C++11/...

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br>Am Mittwoch, 4. Februar 2015 01:47:28 UTC+1 schrieb Da=
vid Krauss:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-=
wrap:break-word"><br><div><div>If you buy into switch with fallthrough bein=
g <i>not</i>&nbsp;broken, then adding new usages without fallthrough is sti=
ll going the wrong way.</div><div><br></div><div>I don=E2=80=99t see the po=
int in encouraging folks to continue using switch, just because it=E2=80=99=
s their habit, especially when switching languages. If you want if-else sem=
antics, write if-else. Optimization is the compiler=E2=80=99s job and it=E2=
=80=99s a little presumptuous to say that it won=E2=80=99t optimize an if-e=
lse strcmp chain. Strcmp is a pure function. Enable profile-guided optimiza=
tion and see what happens.</div><div><br></div><div>Bjarne=E2=80=99s mechan=
ism is pretty cool, but note that it includes its own caching scheme which =
might be better or worse than CPU branch prediction. Measure carefully.</di=
v></div></div></blockquote><div><br></div><div>Who wants to add new usages =
<u>without</u> fallthrough? That would really be a very bad idea. No, the p=
roposal was extended usages for the switch statement, keeping its behaviour=
.. See my example above.</div><div><br></div><div>Sure, we could write that =
by a series of if / if else statements with the very same result. But reada=
bility is very poor in comparison to the proposal. Good readability leads t=
o good / stable software. If C++ code leads to good / stable software more =
people start using this fabulous language again. I can remember Herb Suter =
saying that this was one of the ideas behind C++11/...</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_520_224949985.1423031113186--
------=_Part_519_186817757.1423031113186--

.

--Apple-Mail=_8BD95082-5E6A-4257-9D86-6F9CBA064327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9304, at 2:25 PM, marconef24@gmail.com wrote:
>=20
> Who wants to add new usages without fallthrough?

There was a recent proposal for a =E2=80=9Csafe switch=E2=80=9D in which it=
 would be an error to reach a case label except from the head of the switch=
..

> That would really be a very bad idea. No, the proposal was extended usage=
s for the switch statement, keeping its behaviour. See my example above.

Sorry, I didn=E2=80=99t notice the last example. The first one didn=E2=80=
=99t have any fallthrough.

Yes, the only current way to write a string (or whatever) switch with fallt=
hrough by default is to use an if-else-goto chain followed by a block of na=
med labels guarded by if(false). That=E2=80=99s not very readable.

> Sure, we could write that by a series of if / if else statements with the=
 very same result. But readability is very poor in comparison to the propos=
al. Good readability leads to good / stable software. If C++ code leads to =
good / stable software more people start using this fabulous language again=
.. I can remember Herb Suter saying that this was one of the ideas behind C+=
+11/=E2=80=A6

A lot of folks won=E2=80=99t believe that fallthrough is ever readable, or =
should ever be done in practice.

With an ordinary if-else chain, you can get explicit fallthrough using goto=
 to skip over an else if into the next block:

if (strcmp(s, "bla") =3D=3D 0) {
    doX();
    goto do_ble; // explicit fallthrough

} else if (strcmp(s, "ble") =3D=3D 0) do_ble: {
    doY();

} else if (strcmp(s, "bli") =3D=3D 0) {
    doZ();
}

This is more readable than the switch, hands-down, aside from the noise tha=
t s and strcmp get repeated. That=E2=80=99s what the contention is usually =
about: most programmers want something with less repetition and no fallthro=
ugh.

Using this style for more esoteric control flow such as jumping into the mi=
ddle of a block with uninitialized variables will gradually cause it to deg=
rade into an if-else-goto chain=E2=80=A6 but only gradually. Seriously, exp=
licit or not, pervasive fallthroughs are not conducive to stability and mai=
ntenance.

As for repetition, if that=E2=80=99s really the enemy we should add with(ob=
j) blocks, not reinvent the switch. The recent order of evaluation proposal=
 (N4228) is essentially trying to reinvent the semicolon for the same purpo=
se. Fact is, it=E2=80=99s better to type a little more. References and lamb=
das are there to provide shortcuts.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_8BD95082-5E6A-4257-9D86-6F9CBA064327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9304, at 2:25 PM, <a href=3D"mailto:marconef24@gmail.com" class=3D""=
>marconef24@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newlin=
e"><div class=3D""><div dir=3D"ltr" class=3D"">Who wants to add new usages =
<u class=3D"">without</u> fallthrough?</div></div></blockquote><div><br cla=
ss=3D""></div><div>There was a recent proposal for a =E2=80=9Csafe switch=
=E2=80=9D in which it would be an error to reach a case label except from t=
he head of the switch.</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">That woul=
d really be a very bad idea. No, the proposal was extended usages for the s=
witch statement, keeping its behaviour. See my example above.</div></div></=
div></blockquote><div><br class=3D""></div><div>Sorry, I didn=E2=80=99t not=
ice the last example. The first one didn=E2=80=99t have any fallthrough.</d=
iv><div><br class=3D""></div><div>Yes, the only current way to write a stri=
ng (or whatever) switch with fallthrough <i class=3D"">by default</i> is to=
 use an if-else-goto chain followed by a block of named labels guarded by i=
f(false). That=E2=80=99s not very readable.</div><br class=3D""><blockquote=
 type=3D"cite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Sure,=
 we could write that by a series of if / if else statements with the very s=
ame result. But readability is very poor in comparison to the proposal. Goo=
d readability leads to good / stable software. If C++ code leads to good / =
stable software more people start using this fabulous language again. I can=
 remember Herb Suter saying that this was one of the ideas behind C++11/=E2=
=80=A6</div></div></blockquote><div><br class=3D""></div></div>A lot of fol=
ks won=E2=80=99t believe that fallthrough is ever readable, or should ever =
be done in practice.<div class=3D""><br class=3D""></div><div class=3D"">Wi=
th an ordinary if-else chain, you can get explicit fallthrough using goto t=
o skip over an <font face=3D"Courier" class=3D"">else if</font> into the ne=
xt block:</div><div class=3D""><br class=3D""></div><div class=3D""><div cl=
ass=3D""><font face=3D"Courier" class=3D"">if (strcmp(s, "bla") =3D=3D 0) {=
</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp=
; doX();</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbs=
p; &nbsp; goto do_ble; // explicit fallthrough</font></div><div class=3D"">=
<font face=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D=
""><font face=3D"Courier" class=3D"">} else if (strcmp(s, "ble") =3D=3D 0)&=
nbsp;</font><span style=3D"font-family: Courier;" class=3D"">do_ble:&nbsp;<=
/span><span style=3D"font-family: Courier;" class=3D"">{</span></div><div c=
lass=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; doY();</font></di=
v><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></font><=
/div><div class=3D""><font face=3D"Courier" class=3D"">} else if (strcmp(s,=
 "bli") =3D=3D 0) {</font></div><div class=3D""><font face=3D"Courier" clas=
s=3D"">&nbsp; &nbsp; doZ();</font></div><div class=3D""><font face=3D"Couri=
er" class=3D"">}</font></div></div><div class=3D""><br class=3D""></div><di=
v class=3D"">This is more readable than the switch, hands-down, aside from =
the noise that <font face=3D"Courier" class=3D"">s</font> and <font face=3D=
"Courier" class=3D"">strcmp</font> get repeated. That=E2=80=99s what the co=
ntention is usually about: most programmers want something with less repeti=
tion and no fallthrough.</div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">Using this style for more esoteric control flow such as jumping int=
o the middle of a block with uninitialized variables will gradually cause i=
t to degrade into an if-else-goto chain=E2=80=A6 but only gradually. Seriou=
sly, explicit or not, pervasive fallthroughs are not conducive to stability=
 and maintenance.</div><div class=3D""><br class=3D""></div><div class=3D""=
>As for repetition, if that=E2=80=99s really the enemy we should add <font =
face=3D"Courier" class=3D"">with(obj)</font> blocks, not reinvent the switc=
h. The recent order of evaluation proposal (N4228) is essentially trying to=
 reinvent the semicolon for the same purpose. Fact is, it=E2=80=99s better =
to type a little more. References and lambdas are there to provide shortcut=
s.</div></body></html>

<p></p>

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

--Apple-Mail=_8BD95082-5E6A-4257-9D86-6F9CBA064327--

.

------=_Part_4592_682105293.1423035323987
Content-Type: multipart/alternative;
 boundary="----=_Part_4593_875951765.1423035323987"

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


Am Mittwoch, 4. Februar 2015 08:11:22 UTC+1 schrieb David Krauss:=20
>
> ...=20
>
This is more readable than the switch, hands-down, aside from the noise=20
> that s and strcmp get repeated. That=E2=80=99s what the contention is usu=
ally=20
> about: most programmers want something with less repetition and no=20
> fallthrough.
>

I don't think that examle is well readable. Might be a question of taste as=
=20
well ;-)
=20

> Using this style for more esoteric control flow such as jumping into the=
=20
> middle of a block with uninitialized variables will gradually cause it to=
=20
> degrade into an if-else-goto chain=E2=80=A6 but only gradually. Seriously=
, explicit=20
> or not, pervasive fallthroughs are not conducive to stability and=20
> maintenance.
>

There definitely is a certain danger, but for compatibility reasons that=20
behaviour of the switch won't ever be changed. By good styling and=20
documentation this can be handled quite well, I think (although style=20
guides are another question of taste...):

std::string a;
switch(a)
{
    case "bla":    // fall-through.
    case "ble":    // fall-through.
    case "bli":    doX();
                   // fall-through.
    case "blo":    doY();
                   break;
    case "blu":    doZ();
                   break;
    default:       break;
}

As for repetition, if that=E2=80=99s really the enemy we should add with(ob=
j)=20
> blocks, not reinvent the switch. The recent order of evaluation proposal=
=20
> (N4228) is essentially trying to reinvent the semicolon for the same=20
> purpose. Fact is, it=E2=80=99s better to type a little more. References a=
nd lambdas=20
> are there to provide shortcuts.
>

OT: Is that with(obj) the same as in the old times Pascal?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br>Am Mittwoch, 4. Februar 2015 08:11:22 UTC+1 schrieb Da=
vid Krauss:&nbsp;<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div>...&nbsp;</div></div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div>Th=
is is more readable than the switch, hands-down, aside from the noise that =
<font face=3D"Courier">s</font> and <font face=3D"Courier">strcmp</font> ge=
t repeated. That=E2=80=99s what the contention is usually about: most progr=
ammers want something with less repetition and no fallthrough.</div></div><=
/blockquote><div><br></div><div>I don't think that examle is well readable.=
 Might be a question of taste as well ;-)</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"><div>=
Using this style for more esoteric control flow such as jumping into the mi=
ddle of a block with uninitialized variables will gradually cause it to deg=
rade into an if-else-goto chain=E2=80=A6 but only gradually. Seriously, exp=
licit or not, pervasive fallthroughs are not conducive to stability and mai=
ntenance.</div></div></blockquote><div><br></div><div>There definitely is a=
 certain danger, but for compatibility reasons that behaviour of the switch=
 won't ever be changed. By good styling and documentation this can be handl=
ed quite well, I think (although style guides are another question of taste=
....):</div><div><br></div><div><font face=3D"courier new, monospace">std::s=
tring a;</font></div><div><font face=3D"courier new, monospace">switch(a)</=
font></div><div><font face=3D"courier new, monospace">{</font></div><div><f=
ont face=3D"courier new, monospace">&nbsp; &nbsp; case "bla": &nbsp; &nbsp;=
// fall-through.</font></div><div><font face=3D"courier new, monospace">&nb=
sp; &nbsp; case "ble": &nbsp; &nbsp;// fall-through.</font></div><div><font=
 face=3D"courier new, monospace">&nbsp; &nbsp; case "bli": &nbsp; &nbsp;doX=
();</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// fall-through.</font=
></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; case "blo":=
 &nbsp; &nbsp;doY();</font></div><div><font face=3D"courier new, monospace"=
>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break=
;</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; case=
 "blu": &nbsp; &nbsp;doZ();</font></div><div><font face=3D"courier new, mon=
ospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p;break;</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbs=
p; default: &nbsp; &nbsp; &nbsp; break;</font></div><div><font face=3D"cour=
ier new, monospace">}</font></div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div style=3D"word-wrap:break-word"><div>As for repetiti=
on, if that=E2=80=99s really the enemy we should add <font face=3D"Courier"=
>with(obj)</font> blocks, not reinvent the switch. The recent order of eval=
uation proposal (N4228) is essentially trying to reinvent the semicolon for=
 the same purpose. Fact is, it=E2=80=99s better to type a little more. Refe=
rences and lambdas are there to provide shortcuts.<br></div></div></blockqu=
ote><div><br></div><div>OT: Is that <font face=3D"courier new, monospace">w=
ith(obj)</font> the same as in the old times Pascal?</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_4593_875951765.1423035323987--
------=_Part_4592_682105293.1423035323987--

.

--047d7b343c9c5298b8050e410286
Content-Type: text/plain; charset=UTF-8

>
> It's possible to write such things as libraries without adding core
> language facilities.
> The syntax won't be identical to the built-in switch-case, and I
> consider that a feature.
> A *very* crude approximation that I wrote years ago and didn't bother
> to make prettier
> (I could use a type named 'Case' for the cases, I could allow
> fall-through as an explicit
> option...):
> http://coliru.stacked-crooked.com/a/ee0176042f11b080
>
> Now, we ask ourselves "what the huh? What's the point of that example? We
> don't
> seriously expect every user to write that?" No, we don't expect every
> user to write that.
> The point is that lambdas allow creating new control structures, or
> something very close
> to that. Hence, before a language addition is considered, why not
> consider a library
> algorithm?
>

one of the most serious defficiencies of C++ is indeed the poor switch
implementation.
Lot of things can be done with meta programming...
The problem is that the code becomes often impossible to read and 10
minutes to compile one unit.

I am afraid lot of people are over focused on the possibilities of what
metaprogramming can do rather on being a bit pragmatic and open C++ towards
the "mediocre".

--

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

--047d7b343c9c5298b8050e410286
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">It&#39;s possible to write such things as librar=
ies without adding core<br>
language facilities.<br>
The syntax won&#39;t be identical to the built-in switch-case, and I<br>
consider that a feature.<br>
A *very* crude approximation that I wrote years ago and didn&#39;t bother<b=
r>
to make prettier<br>
(I could use a type named &#39;Case&#39; for the cases, I could allow<br>
fall-through as an explicit<br>
option...):<br>
<a href=3D"http://coliru.stacked-crooked.com/a/ee0176042f11b080" target=3D"=
_blank">http://coliru.stacked-crooked.com/a/ee0176042f11b080</a><br>
<br>
Now, we ask ourselves &quot;what the huh? What&#39;s the point of that exam=
ple? We don&#39;t<br>
seriously expect every user to write that?&quot; No, we don&#39;t expect ev=
ery<br>
user to write that.<br>
The point is that lambdas allow creating new control structures, or<br>
something very close<br>
to that. Hence, before a language addition is considered, why not<br>
consider a library<br>
algorithm?<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><br>
</div><div class=3D"gmail_extra">one of the most serious defficiencies of C=
++ is indeed the poor switch implementation.</div><div class=3D"gmail_extra=
">Lot of things can be done with meta programming...=C2=A0</div><div class=
=3D"gmail_extra">The problem is that the code becomes often impossible to r=
ead and 10 minutes to compile one unit.</div><div class=3D"gmail_extra"><br=
>I am afraid lot of people are over focused on the possibilities of what me=
taprogramming can do rather on being a bit pragmatic and open C++ towards t=
he &quot;mediocre&quot;.=C2=A0</div><div class=3D"gmail_extra"><br></div></=
div>

<p></p>

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

--047d7b343c9c5298b8050e410286--

.

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

>
> How about the code presented in this paper?
> http://www.stroustrup.com/OpenPatternMatching.pdf
> As far as I understand, it can "switch" (aka Match) on both types and
> value.
>

Wanted to ask, what about turning towards an implementation like Swift is
doing (and other languages ), with pattern matching, and this link came in.
I think I would need to go up to the mountains for brain-oxygen for one
week to be able to read that paper :) Well I am sure it was not written in
one day....
I also would be more than curious to read examples.

--

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

--001a1133201878e56e050e4139bb
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">How about the code presented in this paper?<br>
<a href=3D"http://www.stroustrup.com/OpenPatternMatching.pdf" target=3D"_bl=
ank">http://www.stroustrup.com/OpenPatternMatching.pdf</a><br>
As far as I understand, it can &quot;switch&quot; (aka Match) on both types=
 and value.<br></blockquote><div><br></div><div>Wanted to ask, what about t=
urning towards an implementation like Swift is doing (and other languages )=
, with pattern matching, and this link came in.</div><div>I think I would n=
eed to go up to the mountains for brain-oxygen for one week to be able to r=
ead that paper :) Well I am sure it was not written in one day....</div><di=
v>I also would be more than curious to read examples.<br></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 />

--001a1133201878e56e050e4139bb--

.

------=_Part_243_1435785532.1423050670640
Content-Type: multipart/alternative;
 boundary="----=_Part_244_2121178632.1423050670640"

------=_Part_244_2121178632.1423050670640
Content-Type: text/plain; charset=UTF-8


Am Mittwoch, 4. Februar 2015 11:54:20 UTC+1 schrieb mobiphil:

> one of the most serious defficiencies of C++ is indeed the poor switch
> implementation. Lot of things can be done with meta programming...
> The problem is that the code becomes often impossible to read and 10
> minutes to compile one unit.
>
> I am afraid lot of people are over focused on the possibilities of what
> metaprogramming can do rather on being a bit pragmatic and open C++ towards
> the "mediocre".
>
>
If there were a like button I would press it :-)

Indeed many of the new features are very academic and - although I like
them as I love metaprogramming - of little use for the majority of the
programmers.

--

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

<div dir=3D"ltr"><br>Am Mittwoch, 4. Februar 2015 11:54:20 UTC+1 schrieb mo=
biphil:<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>one of the most serious defficiencies of C++ is indeed the poor switch =
implementation. Lot of things can be done with meta programming...&nbsp;</d=
iv><div>The problem is that the code becomes often impossible to read and 1=
0 minutes to compile one unit.</div><div><br>I am afraid lot of people are =
over focused on the possibilities of what metaprogramming can do rather on =
being a bit pragmatic and open C++ towards the "mediocre".&nbsp;</div><div>=
<br></div></div></blockquote><div><br></div><div>If there were a like butto=
n I would press it :-)</div><div><br></div><div>Indeed many of the new feat=
ures are very academic and - although I like them as I love metaprogramming=
 - of little use for the majority of the programmers.&nbsp;</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 />

------=_Part_244_2121178632.1423050670640--
------=_Part_243_1435785532.1423050670640--

.

------=_Part_6435_2061897462.1423079785772
Content-Type: multipart/alternative;
 boundary="----=_Part_6436_367032195.1423079785772"

------=_Part_6436_367032195.1423079785772
Content-Type: text/plain; charset=UTF-8

Just for fun as I was just implementing a similar thing... if you don't
need fallthrough, this might be an easy solution as some of the above
comments wish to be done like:

const char *pcValue = ...;

static struct
{   const char *pcCase;
    std::function<void()> handler;
} pCases
{   { "bla", []() { doBla(); } },
    { "ble", []() { doBle(); } },
    { "bli", []() { doBli(); } },
    ...
};
for(const auto &rCase : pCases)
{   if(std::strcmp(rCase.pcCase, pcValue) == 0)
    {   rCase.handler();
    }
}

--

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

<div dir=3D"ltr">Just for fun as I was just implementing a similar thing...=
 if you don't need fallthrough, this might be an easy solution as some of t=
he above comments wish to be done like:<div><br></div><div><font face=3D"co=
urier new, monospace">const char *pcValue =3D ...;</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">static struct</font></div><div><font face=3D"courier new, m=
onospace">{ &nbsp; const char *pcCase;</font></div><div><font face=3D"couri=
er new, monospace">&nbsp; &nbsp; std::function&lt;void()&gt; handler;</font=
></div><div><font face=3D"courier new, monospace">} pCases</font></div><div=
><font face=3D"courier new, monospace">{ &nbsp; { "bla", []() { doBla(); } =
},</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; { "=
ble", []() { doBle(); } },</font></div><div><span style=3D"font-family: 'co=
urier new', monospace;">&nbsp; &nbsp; { "bli", []() { doBli(); } },</span><=
font face=3D"courier new, monospace"><br></font></div><div><span style=3D"f=
ont-family: 'courier new', monospace;">&nbsp; &nbsp; ...</span></div><div><=
span style=3D"font-family: 'courier new', monospace;">};</span></div><div><=
span style=3D"font-family: 'courier new', monospace;">for(const auto &amp;r=
Case : pCases)</span></div><div><span style=3D"font-family: 'courier new', =
monospace;">{ &nbsp; if(std::strcmp(rCase.pcCase, pcValue) =3D=3D 0)</span>=
</div><div><span style=3D"font-family: 'courier new', monospace;">&nbsp; &n=
bsp; { &nbsp; rCase.handler();</span></div><div><span style=3D"font-family:=
 'courier new', monospace;">&nbsp; &nbsp; }</span></div><div><span style=3D=
"font-family: 'courier new', monospace;">}</span></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_6436_367032195.1423079785772--
------=_Part_6435_2061897462.1423079785772--

.

------=_Part_786_499482614.1423080006085
Content-Type: multipart/alternative;
 boundary="----=_Part_787_290717375.1423080006085"

------=_Part_787_290717375.1423080006085
Content-Type: text/plain; charset=UTF-8

I don't like macros, but using them this could be made quite readable:

BEGIN_STRING_SWITCH
  ADD_CASE("bla", doBla())
  ADD_CASE("ble", doBle())
  ADD_CASE("bli", doBli())
  ...
END_STRING_SWITCH

--

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

<div dir=3D"ltr">I don't like macros, but using them this could be made qui=
te readable:<br><br><font face=3D"courier new, monospace">BEGIN_STRING_SWIT=
CH</font><div><font face=3D"courier new, monospace">&nbsp; ADD_CASE("bla", =
doBla())</font></div><div><font face=3D"courier new, monospace">&nbsp; ADD_=
CASE("ble", doBle())</font></div><div><font face=3D"courier new, monospace"=
>&nbsp; ADD_CASE("bli", doBli())</font></div><div><font face=3D"courier new=
, monospace">&nbsp; ...</font></div><div><font face=3D"courier new, monospa=
ce">END_STRING_SWITCH</font></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_787_290717375.1423080006085--
------=_Part_786_499482614.1423080006085--

.

The main use for fallthrough is for multiple values to map to
equivalent code.  How would you do e.g. "foo"|"bar"?

On 2/4/15, marconef24@gmail.com <marconef24@gmail.com> wrote:
> I don't like macros, but using them this could be made quite readable:
>
> BEGIN_STRING_SWITCH
>   ADD_CASE("bla", doBla())
>   ADD_CASE("ble", doBle())
>   ADD_CASE("bli", doBli())
>   ...
> END_STRING_SWITCH
>
> --
>
> ---
> 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/.

.

--Apple-Mail=_2D98E3EA-4833-4B14-A811-6221720AC855
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9304, at 3:35 PM, marconef24@gmail.com wrote:
>=20
> OT: Is that with(obj) the same as in the old times Pascal?

Yep. There=E2=80=99s also the Visual Basic variation which defines a unary =
dot operator.

The theme is implied variables: for switch, the value of the condition; for=
 object chaining, the return *this value provided by chainable methods.

We want to take advantage of the information that=E2=80=99s conveniently na=
med in a particular context, so we produce that context when it=E2=80=99s n=
ot appropriate. It=E2=80=99s abuse, and it leads to corrosion of the main u=
se-cases that drove language design in the first place.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_2D98E3EA-4833-4B14-A811-6221720AC855
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9304, at 3:35 PM, <a href=3D"mailto:marconef24@gmail.com" class=3D""=
>marconef24@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newlin=
e"><div class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-s=
ize: 12px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: normal; orphans: auto; text-align: star=
t; text-indent: 0px; text-transform: none; white-space: normal; widows: aut=
o; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div clas=
s=3D"">OT: Is that<span class=3D"Apple-converted-space">&nbsp;</span><font =
face=3D"courier new, monospace" class=3D"">with(obj)</font><span class=3D"A=
pple-converted-space">&nbsp;</span>the same as in the old times Pascal?</di=
v></div></div></blockquote></div><br class=3D""><div class=3D"">Yep. There=
=E2=80=99s also the Visual Basic variation which defines a unary dot operat=
or.</div><div class=3D""><br class=3D""></div><div class=3D"">The theme is =
implied variables: for <font face=3D"Courier" class=3D"">switch</font>, the=
 value of the condition; for object chaining, the <font face=3D"Courier" cl=
ass=3D"">return *this</font> value provided by chainable methods.</div><div=
 class=3D""><br class=3D""></div><div class=3D"">We want to take advantage =
of the information that=E2=80=99s conveniently named in a particular contex=
t, so we produce that context when it=E2=80=99s not appropriate. It=E2=80=
=99s abuse, and it leads to corrosion of the main use-cases that drove lang=
uage design in the first place.</div></body></html>

<p></p>

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

--Apple-Mail=_2D98E3EA-4833-4B14-A811-6221720AC855--

.

------=_Part_4407_236732443.1423123044184
Content-Type: multipart/alternative;
 boundary="----=_Part_4408_1622455257.1423123044184"

------=_Part_4408_1622455257.1423123044184
Content-Type: text/plain; charset=UTF-8

Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Douglas Boffey:
>
> The main use for fallthrough is for multiple values to map to
> equivalent code.  How would you do e.g. "foo"|"bar"?
>

Not at all, as I wrote in the intial example without macros. That's why I
would love an extended switch statement.

--

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

<div dir=3D"ltr">Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Doug=
las Boffey:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The main use for fa=
llthrough is for multiple values to map to
<br>equivalent code. &nbsp;How would you do e.g. "foo"|"bar"?
<br></blockquote><div><br></div><div>Not at all, as I wrote in the intial e=
xample without macros. That's why I would love an extended switch statement=
..&nbsp;</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_4408_1622455257.1423123044184--
------=_Part_4407_236732443.1423123044184--

.

------=_Part_4591_1775749573.1423135646073
Content-Type: multipart/alternative;
 boundary="----=_Part_4592_1442831052.1423135646073"

------=_Part_4592_1442831052.1423135646073
Content-Type: text/plain; charset=UTF-8

The underlying problem with switch is that each case can take only one
value.  Consider Pascal, for example, where the select statement can take
cases of the form:

case 1, 3, 5 .. 7:

and this is a consequence of the definition of the , (comma) operator.

Sadly, that ship has sailed many, many, many moons ago.
On Thursday, 5 February 2015 07:57:24 UTC, marco...@gmail.com wrote:

> Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Douglas Boffey:
>>
>> The main use for fallthrough is for multiple values to map to
>> equivalent code.  How would you do e.g. "foo"|"bar"?
>>
>
> Not at all, as I wrote in the intial example without macros. That's why I
> would love an extended switch statement.
>

--

---
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_4592_1442831052.1423135646073
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><DIV>The underlying problem with switch is that each case can take only one value.&nbsp; Consider Pascal, for example, where the select statement can take cases of the form:</DIV>
<DIV>&nbsp;</DIV>
<DIV>case 1, 3, 5 .. 7:</DIV>
<DIV>&nbsp;</DIV>
<DIV>and this is a consequence of the definition of the , (comma) operator.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Sadly, that ship has sailed many, many, many moons ago.<BR></DIV>
<DIV>On Thursday, 5 February 2015 07:57:24 UTC, marco...@gmail.com wrote:</DIV>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV dir=ltr>Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Douglas Boffey:
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>The main use for fallthrough is for multiple values to map to <BR>equivalent code. &nbsp;How would you do e.g. "foo"|"bar"? <BR></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Not at all, as I wrote in the intial example without macros. That's why I would love an extended switch statement.&nbsp;</DIV></DIV></BLOCKQUOTE></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_4592_1442831052.1423135646073--
------=_Part_4591_1775749573.1423135646073--

.

------=_Part_17_575918900.1423175682227
Content-Type: multipart/alternative;
 boundary="----=_Part_18_701057513.1423175682233"

------=_Part_18_701057513.1423175682233
Content-Type: text/plain; charset=UTF-8



On Friday, February 6, 2015 at 12:27:26 AM UTC+13, Douglas Boffey wrote:
>
> The underlying problem with switch is that each case can take only one
> value.  Consider Pascal, for example, where the select statement can take
> cases of the form:
>
> case 1, 3, 5 .. 7:
>
> and this is a consequence of the definition of the , (comma) operator.
>
> Sadly, that ship has sailed many, many, many moons ago.
> On Thursday, 5 February 2015 07:57:24 UTC, marco...@gmail.com wrote:
>
>> Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Douglas Boffey:
>>>
>>> The main use for fallthrough is for multiple values to map to
>>> equivalent code.  How would you do e.g. "foo"|"bar"?
>>>
>>
>> Not at all, as I wrote in the intial example without macros. That's why I
>> would love an extended switch statement.
>>
>


On Friday, February 6, 2015 at 12:27:26 AM UTC+13, Douglas Boffey wrote:
>
> The underlying problem with switch is that each case can take only one
> value.  Consider Pascal, for example, where the select statement can take
> cases of the form:
>
> case 1, 3, 5 .. 7:
>
> and this is a consequence of the definition of the , (comma) operator.
>
> Sadly, that ship has sailed many, many, many moons ago.
> On Thursday, 5 February 2015 07:57:24 UTC, marco...@gmail.com wrote:
>
>> Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Douglas Boffey:
>>>
>>> The main use for fallthrough is for multiple values to map to
>>> equivalent code.  How would you do e.g. "foo"|"bar"?
>>>
>>
>> Not at all, as I wrote in the intial example without macros. That's why I
>> would love an extended switch statement.
>>
>
Crazy thought, but I wonder: maybe overloading comma should be deprecated
then removed?

Others seem to be thinking of removing it. See 'D' where the idea seems to
have a lot of support including Andrei.
http://forum.dlang.org/thread/lgnhqd$1de5$1@digitalmars.com

In C++, the suggestion often appears that the comma operator should NEVER
be overloaded anyway.
http://stackoverflow.com/questions/5602112/when-to-overload-the-comma-operator

Tracking down existing breakages could be a problem? But perhaps it could
be managed like this: allow the overload operator comma declarations be
accepted by the compiler and discouraged people from removing them for a
time, but then use that to warn the user that "usages" of that definition
are actually being ignored, so the user can find and replace that code
because the compiler is telling them exactly where the problem is by
warning or failing on the actual use. If that makes sense?


--

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

<div dir=3D"ltr"><br><br>On Friday, February 6, 2015 at 12:27:26 AM UTC+13,=
 Douglas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Th=
e underlying problem with switch is that each case can take only one value.=
&nbsp; Consider Pascal, for example, where the select statement can take ca=
ses of the form:</div>
<div>&nbsp;</div>
<div>case 1, 3, 5 .. 7:</div>
<div>&nbsp;</div>
<div>and this is a consequence of the definition of the , (comma) operator.=
</div>
<div>&nbsp;</div>
<div>Sadly, that ship has sailed many, many, many moons ago.<br></div>
<div>On Thursday, 5 February 2015 07:57:24 UTC, <a>marco...@gmail.com</a> w=
rote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">
<div dir=3D"ltr">Am Donnerstag, 5. Februar 2015 00:22:52 UTC+1 schrieb Doug=
las Boffey:=20
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">The main use for fallthrough is for multiple v=
alues to map to <br>equivalent code. &nbsp;How would you do e.g. "foo"|"bar=
"? <br></blockquote>
<div><br></div>
<div>Not at all, as I wrote in the intial example without macros. That's wh=
y I would love an extended switch statement.&nbsp;</div></div></blockquote>=
</div></blockquote><div><br></div><div><br><br>On Friday, February 6, 2015 =
at 12:27:26 AM UTC+13, Douglas Boffey wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color=
: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><d=
iv dir=3D"ltr"><div>The underlying problem with switch is that each case ca=
n take only one value.&nbsp; Consider Pascal, for example, where the select=
 statement can take cases of the form:</div><div>&nbsp;</div><div>case 1, 3=
, 5 .. 7:</div><div>&nbsp;</div><div>and this is a consequence of the defin=
ition of the , (comma) operator.</div><div>&nbsp;</div><div>Sadly, that shi=
p has sailed many, many, many moons ago.<br></div><div>On Thursday, 5 Febru=
ary 2015 07:57:24 UTC, <a>marco...@gmail.com</a> wrote:</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div dir=3D"ltr">Am Donnerstag, 5. Februar 2015 00:22:52 UTC=
+1 schrieb Douglas Boffey:  <blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">The main use for f=
allthrough is for multiple values to map to <br>equivalent code. &nbsp;How =
would you do e.g. "foo"|"bar"? <br></blockquote><div><br></div><div>Not at =
all, as I wrote in the intial example without macros. That's why I would lo=
ve an extended switch statement.&nbsp;</div></div></blockquote></div></bloc=
kquote><div><br></div><div>Crazy thought, but I wonder: maybe overloading c=
omma&nbsp;should be deprecated then removed?</div><div><br></div><div>Other=
s seem to be thinking&nbsp;of removing it.&nbsp;See 'D' where&nbsp;the idea=
 seems to have a lot of support including Andrei.</div><div><a href=3D"http=
://forum.dlang.org/thread/lgnhqd$1de5$1@digitalmars.com">http://forum.dlang=
..org/thread/lgnhqd$1de5$1@digitalmars.com</a></div><div><br></div><div><div=
>In C++, the suggestion often appears&nbsp;that the comma operator should N=
EVER be overloaded anyway.</div></div><div><a href=3D"http://stackoverflow.=
com/questions/5602112/when-to-overload-the-comma-operator">http://stackover=
flow.com/questions/5602112/when-to-overload-the-comma-operator</a></div><di=
v><br></div><div>Tracking down existing breakages could be a problem? But p=
erhaps&nbsp;it could be managed&nbsp;like this:&nbsp;allow the&nbsp;overloa=
d&nbsp;operator comma&nbsp;declarations&nbsp;be accepted&nbsp;by the compil=
er and discouraged people from removing them for a time, but&nbsp;then use =
that to warn the user that&nbsp;"usages" of that definition are actually&nb=
sp;being ignored, so the user can find and replace that code because the co=
mpiler is telling them exactly where the problem is by warning&nbsp;or fail=
ing on the actual use. If that makes sense?</div>&nbsp;</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_18_701057513.1423175682233--
------=_Part_17_575918900.1423175682227--

.

------=_Part_953_1782606297.1423324714496
Content-Type: multipart/alternative;
 boundary="----=_Part_954_719674382.1423324714496"

------=_Part_954_719674382.1423324714496
Content-Type: text/plain; charset=UTF-8

I don't think of the primary benefit to switch being optimization purposes,
but because I find it the most readable. if-else chains require repeating
the condition, which makes it possible to make a mistake.

That being said, the alternatives to switch may theoretically be
optimizable, but in practice they are not. We do not have a sufficiently
smart compiler to do anything, and without profile-guided optimization,
we're a long way away.

gcc, for instance, does not 'optimize' an if-else chain into a switch
statement because that isn't always an optimization. The first value or two
of the if statement is checked faster than the values of a switch
statement. If gcc made that optimization, then users who put their most
common condition first in an if statement could be penalized. clang, on the
other hand, will make that optimization, which is the correct thing to do
if the first one or two statements are not much more common.

The code generated by std::map or std::unordered_map is also much worse
than that generated by switch (dynamic allocation and indirect access to
memory that has a good chance of being out of cache).

--

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

<div dir=3D"ltr">I don't think of the primary benefit to switch being optim=
ization purposes, but because I find it the most readable. if-else chains r=
equire repeating the condition, which makes it possible to make a mistake.<=
br><br>That being said, the alternatives to switch may theoretically be opt=
imizable, but in practice they are not. We do not have a sufficiently smart=
 compiler to do anything, and without profile-guided optimization, we're a =
long way away.<br><br>gcc, for instance, does not 'optimize' an if-else cha=
in into a switch statement because that isn't always an optimization. The f=
irst value or two of the if statement is checked faster than the values of =
a switch statement. If gcc made that optimization, then users who put their=
 most common condition first in an if statement could be penalized. clang, =
on the other hand, will make that optimization, which is the correct thing =
to do if the first one or two statements are not much more common.<br><br>T=
he code generated by std::map or std::unordered_map is also much worse than=
 that generated by switch (dynamic allocation and indirect access to memory=
 that has a good chance of being out of cache).<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_954_719674382.1423324714496--
------=_Part_953_1782606297.1423324714496--

.

On 7 February 2015 at 17:58, David Stone <deusexsophismata@gmail.com> wrote:
> I don't think of the primary benefit to switch being optimization purposes,
> but because I find it the most readable. if-else chains require repeating
> the condition, which makes it possible to make a mistake.

I think the apparent readability of switch is questionable. Anecdotal as it
may be, I have for while treated switch as an indication of "here be bugs"
and "here be a very indeterminate state machine that nobody can maintain".

> That being said, the alternatives to switch may theoretically be
> optimizable, but in practice they are not. We do not have a sufficiently
> smart compiler to do anything, and without profile-guided optimization,
> we're a long way away.

Ah, yes - optimization possibilities. A switch on a pod-like type
may well be optimizable to a table lookup, but how do we do such
a table lookup if the comparison of the type of the switched object
is not optimizable? That's the gist of my doubts on enhancing
switch - while there may be possibilities to write straightforward
code that superficially looks clean and simple, we are likely
to completely miss the optimization possibilities switch (or as I
call it, an 'always forward-jumping goto') allows.

My gut feeling is that enhancing switch and making it more palatable
to users may well not be worth the cost, and may not be a design direction
we want to advocate.

--

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

.

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

>
> On 7 February 2015 at 17:58, David Stone <deusexsophismata@gmail.com>
> wrote:
> > I don't think of the primary benefit to switch being optimization
> purposes,
> > but because I find it the most readable. if-else chains require repeating
> > the condition, which makes it possible to make a mistake.
>
> I think the apparent readability of switch is questionable. Anecdotal as it
> may be, I have for while treated switch as an indication of "here be bugs"
> and "here be a very indeterminate state machine that nobody can maintain".
>

there are tons of anecdotes about constructs, my favorite one is with goto.
Was afraid to touch goto for long years, believed this psycho professor at
the university how harmful it would be. It is like do not touch motorbikes
'cause they would kill you. While often all these are echos of some
personal coding traumas, I do not think that a switch statement could be in
any way measure of likelihood of bugs. I wonder how would you write a
trivial lexer without a huge switch. Well, you could with tons of if's but
I would get dizzy about reading it and could not even care about the bugs.


> That being said, the alternatives to switch may theoretically be
> > optimizable, but in practice they are not. We do not have a sufficiently
> > smart compiler to do anything, and without profile-guided optimization,
> > we're a long way away.
>
> Ah, yes - optimization possibilities. A switch on a pod-like type
> may well be optimizable to a table lookup, but how do we do such
> a table lookup if the comparison of the type of the switched object
> is not optimizable? That's the gist of my doubts on enhancing
> switch - while there may be possibilities to write straightforward
> code that superficially looks clean and simple, we are likely
> to completely miss the optimization possibilities switch (or as I
> call it, an 'always forward-jumping goto') allows.
>
> My gut feeling is that enhancing switch and making it more palatable
> to users may well not be worth the cost, and may not be a design direction
> we want to advocate.
>

Early analyze/ optimize/paralyze, is yet another useless perfectionism.
Most algorithm 90% of time is spent in 10% of code. Make that 10%
hyper/super optimized, but leave the rest of 90% elegant, and allow elegant
construct with hype/super fancy constructs even pattern matching, or
whatsoever it would be, with the simple objective to improve readability to
decrease likelihood for bugs.

Do not see too much added value of expressing superficial conclusions about
what is worth the cost based on even more superficial analysis.

Pattern matching was introduced in lot of languages, not because somebody
wanted to have fun, for the simple reason, it proved to be important. Chris
Latner behind Swift, who started the Clang compiler project insisted to
implement pattern matching into the switch case of the language. Try to
explain Apple that it is not worth the cost, you will fail. For  the simple
reason that you are not right.

--

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

--001a1133201837e28a050e82f88b
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"><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"><span>On 7 February 2015 at 17:58, David Stone &lt;<a href=3D"=
mailto:deusexsophismata@gmail.com" target=3D"_blank">deusexsophismata@gmail=
..com</a>&gt; wrote:<br>
&gt; I don&#39;t think of the primary benefit to switch being optimization =
purposes,<br>
&gt; but because I find it the most readable. if-else chains require repeat=
ing<br>
&gt; the condition, which makes it possible to make a mistake.<br>
<br>
</span>I think the apparent readability of switch is questionable. Anecdota=
l as it<br>
may be, I have for while treated switch as an indication of &quot;here be b=
ugs&quot;<br>
and &quot;here be a very indeterminate state machine that nobody can mainta=
in&quot;.<br></blockquote><div><br></div><div>there are tons of anecdotes a=
bout constructs, my favorite one is with goto. Was afraid to touch goto for=
 long years, believed this psycho professor at the university how harmful i=
t would be. It is like do not touch motorbikes &#39;cause they would kill y=
ou. While often all these are echos of some personal coding traumas, I do n=
ot think that a switch statement could be in any way measure of likelihood =
of bugs. I wonder how would you write a trivial lexer without a huge switch=
.. Well, you could with tons of if&#39;s but I would get dizzy about reading=
 it and could not even care about the bugs.=C2=A0</div><div><br></div><div>=
<br></div><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"><span>&gt; That being said, the alternatives to =
switch may theoretically be<br>
&gt; optimizable, but in practice they are not. We do not have a sufficient=
ly<br>
&gt; smart compiler to do anything, and without profile-guided optimization=
,<br>
&gt; we&#39;re a long way away.<br>
<br>
</span>Ah, yes - optimization possibilities. A switch on a pod-like type<br=
>
may well be optimizable to a table lookup, but how do we do such<br>
a table lookup if the comparison of the type of the switched object<br>
is not optimizable? That&#39;s the gist of my doubts on enhancing<br>
switch - while there may be possibilities to write straightforward<br>
code that superficially looks clean and simple, we are likely<br>
to completely miss the optimization possibilities switch (or as I<br>
call it, an &#39;always forward-jumping goto&#39;) allows.<br>
<br>
My gut feeling is that enhancing switch and making it more palatable<br>
to users may well not be worth the cost, and may not be a design direction<=
br>
we want to advocate.<br></blockquote><div><br></div><div>Early analyze/=C2=
=A0optimize/paralyze, is yet another useless perfectionism. Most algorithm =
90% of time is spent in 10% of code. Make that 10% hyper/super optimized, b=
ut leave the rest of 90% elegant, and allow elegant construct with hype/sup=
er fancy constructs even pattern matching, or whatsoever it would be, with =
the simple objective to improve readability to decrease likelihood for bugs=
..=C2=A0</div><div><br></div><div>Do not see too much added value of express=
ing superficial conclusions about what is worth the cost based on even more=
 superficial analysis.</div><div><br></div><div>Pattern matching was introd=
uced in lot of languages, not because somebody wanted to have fun, for the =
simple reason, it proved to be important. Chris Latner behind Swift, who st=
arted the Clang compiler project insisted to implement pattern matching int=
o the switch case of the language. Try to explain Apple that it is not wort=
h the cost, you will fail. For =C2=A0the simple reason that you are not rig=
ht.</div><div><br></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 />

--001a1133201837e28a050e82f88b--

.

On 7 February 2015 at 19:35, mobi phil <mobi@mobiphil.com> wrote:
>> I think the apparent readability of switch is questionable. Anecdotal as
>> it
>> may be, I have for while treated switch as an indication of "here be bugs"
>> and "here be a very indeterminate state machine that nobody can maintain".
> there are tons of anecdotes about constructs, my favorite one is with goto.
> Was afraid to touch goto for long years, believed this psycho professor at
> the university how harmful it would be. It is like do not touch motorbikes

I am fully aware of the fact that quite many people misunderstand what
eg. Dijkstra wrote, or didn't even bother reading what he wrote and
rather resorted
to broken-phones-hearsay. I am not saying goto or switch are inherently
bad, I'm just saying we shouldn't necessarily promote either of them.

Btw, I mentioned Dijkstra just because he's often referred to in discussions
about jumping statements. I do not claim nor do I condone that he was
ever a "psycho professor". The excrement that usually goes on on this
forum is well beneath his achievements.

> Pattern matching was introduced in lot of languages, not because somebody

Well, perhaps we should then consider pattern matching, rather than
enhancing the switch we currently have. Chances are that pattern matching
is not going to be an enhancement to switch and will not quite look like
a switch.

--

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

.

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

>
> On 7 February 2015 at 19:35, mobi phil <mobi@mobiphil.com> wrote:
> >> I think the apparent readability of switch is questionable. Anecdotal as
> >> it
> >> may be, I have for while treated switch as an indication of "here be
> bugs"
> >> and "here be a very indeterminate state machine that nobody can
> maintain".
> > there are tons of anecdotes about constructs, my favorite one is with
> goto.
> > Was afraid to touch goto for long years, believed this psycho professor
> at
> > the university how harmful it would be. It is like do not touch
> motorbikes
>
> I am fully aware of the fact that quite many people misunderstand what
> eg. Dijkstra wrote, or didn't even bother reading what he wrote and
> rather resorted
> to broken-phones-hearsay. I am not saying goto or switch are inherently
> bad, I'm just saying we shouldn't necessarily promote either of them.
>

C++ should not be thought as a Kindergarten lesson. Everybody should have
his own freedom to decide how, when and why to use certain construct. While
I see an advice as reasonable, thinking in terms of promote or not to
promote a construct find it rather exaggerated. Promote by whom to whom?
Who has the right to promote? Or who shall think he/she has the right to
promote? Personally I am tired of experiences, where somebody comes to
preach about how wrong a particular construct is, and the argument often
sounds like: "Don't know how to tell you, why just you don't understand
that goto is wrong" and you see how his face is becoming red as he is
deeply embarrassed about his own bluff.

Treating case by case such constructs is one thing, writing kind of recipes
when how and why to use a certain construct, but to discourage on general
bases: NO.

Was recently reading about the so called data oriented design/programming.
The person behind fairly describes inheritance and other C++ artifacts as
bad due to cache coherency issues they introduce. He is right for all the
cases where this cache in-coherency would severely affect performance.
Well, I would discourage nobody to use inheritance and polimorfism
generally: I would just say: think twice.

Every and each C++ programmer could write his blacklist. I would put in the
front if(a=b) and not goto. Swift for instance forbids it. Result of assign
is not an rvalue, it is nothing, thus cannot be used in if. Matter of
taste, experience and the particular domain where she/he uses the language.


> Btw, I mentioned Dijkstra just because he's often referred to in
> discussions
> about jumping statements. I do not claim nor do I condone that he was
> ever a "psycho professor". The excrement that usually goes on on this
> forum is well beneath his achievements.
>

I am afraid that somebody would now make the association that I would
called him psycho professor, while I just mentioned a professor from the
University where I studied.


> > Pattern matching was introduced in lot of languages, not because somebody
>
> Well, perhaps we should then consider pattern matching, rather than
> enhancing the switch we currently have. Chances are that pattern matching
> is not going to be an enhancement to switch and will not quite look like
> a switch.
>

In lot of the simple case of the pattern matching looks like a switch.

--

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

--001a1135ffb8e6c28c050e84f4e9
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">On 7 February 2015 at 19:35, mo=
bi phil &lt;<a href=3D"mailto:mobi@mobiphil.com">mobi@mobiphil.com</a>&gt; =
wrote:<br>
&gt;&gt; I think the apparent readability of switch is questionable. Anecdo=
tal as<br>
&gt;&gt; it<br>
&gt;&gt; may be, I have for while treated switch as an indication of &quot;=
here be bugs&quot;<br>
&gt;&gt; and &quot;here be a very indeterminate state machine that nobody c=
an maintain&quot;.<br>
&gt; there are tons of anecdotes about constructs, my favorite one is with =
goto.<br>
&gt; Was afraid to touch goto for long years, believed this psycho professo=
r at<br>
&gt; the university how harmful it would be. It is like do not touch motorb=
ikes<br>
<br>
</span>I am fully aware of the fact that quite many people misunderstand wh=
at<br>
eg. Dijkstra wrote, or didn&#39;t even bother reading what he wrote and<br>
rather resorted<br>
to broken-phones-hearsay. I am not saying goto or switch are inherently<br>
bad, I&#39;m just saying we shouldn&#39;t necessarily promote either of the=
m.<br></blockquote><div><br></div><div>C++ should not be thought as a Kinde=
rgarten lesson. Everybody should have his own freedom to decide how, when a=
nd why to use certain construct. While I see an advice as reasonable, think=
ing in terms of promote or not to promote a construct find it rather exagge=
rated. Promote by whom to whom? Who has the right to promote? Or who shall =
think he/she has the right to promote? Personally I am tired of experiences=
, where somebody comes to preach about how wrong a particular construct is,=
 and the argument often sounds like: &quot;Don&#39;t know how to tell you, =
why just you don&#39;t understand that goto is wrong&quot; and you see how =
his face is becoming red as he is deeply embarrassed about his own bluff.=
=C2=A0</div><div><br></div><div>Treating case by case such constructs is on=
e thing, writing kind of recipes when how and why to use a certain construc=
t, but to discourage on general bases: NO.</div><div><br></div><div>Was rec=
ently reading about the so called data oriented design/programming. The per=
son behind fairly describes inheritance and other C++ artifacts as bad due =
to cache coherency issues they introduce. He is right for all the cases whe=
re this cache in-coherency would severely affect performance. Well, I would=
 discourage nobody to use inheritance and polimorfism generally: I would ju=
st say: think twice.</div><div><br></div><div>Every and each C++ programmer=
 could write his blacklist. I would put in the front if(a=3Db) and not goto=
.. Swift for instance forbids it. Result of assign is not an rvalue, it is n=
othing, thus cannot be used in if. Matter of taste, experience and the part=
icular domain where she/he uses the language.</div><div>=C2=A0<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">Btw, I mentioned Dijkstra just because he&#39;s=
 often referred to in discussions<br>
about jumping statements. I do not claim nor do I condone that he was<br>
ever a &quot;psycho professor&quot;. The excrement that usually goes on on =
this<br>
forum is well beneath his achievements.<br></blockquote><div>=C2=A0</div><d=
iv>I am afraid that somebody would now make the association that I would ca=
lled him psycho professor, while I just mentioned a professor from the Univ=
ersity where I studied.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">&gt; Pattern matching was introduced in lot of languages=
, not because somebody<br>
<br>
</span>Well, perhaps we should then consider pattern matching, rather than<=
br>
enhancing the switch we currently have. Chances are that pattern matching<b=
r>
is not going to be an enhancement to switch and will not quite look like<br=
>
a switch.<br></blockquote><div><br></div><div>In lot of the simple case of =
the pattern matching looks like a switch.</div><div><br></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 />

--001a1135ffb8e6c28c050e84f4e9--

.

------=_Part_14_692010599.1423428398616
Content-Type: multipart/alternative;
 boundary="----=_Part_15_1998188888.1423428398616"

------=_Part_15_1998188888.1423428398616
Content-Type: text/plain; charset=UTF-8



On Sunday, February 8, 2015 at 6:53:58 AM UTC+13, Ville Voutilainen wrote:
>
> On 7 February 2015 at 19:35, mobi phil <mo...@mobiphil.com <javascript:>>
> wrote:
> >> I think the apparent readability of switch is questionable. Anecdotal
> as
> >> it
> >> may be, I have for while treated switch as an indication of "here be
> bugs"
> >> and "here be a very indeterminate state machine that nobody can
> maintain".
> > there are tons of anecdotes about constructs, my favorite one is with
> goto.
> > Was afraid to touch goto for long years, believed this psycho professor
> at
> > the university how harmful it would be. It is like do not touch
> motorbikes
>
> I am fully aware of the fact that quite many people misunderstand what
> eg. Dijkstra wrote, or didn't even bother reading what he wrote and
> rather resorted
> to broken-phones-hearsay. I am not saying goto or switch are inherently
> bad, I'm just saying we shouldn't necessarily promote either of them.
>
> Btw, I mentioned Dijkstra just because he's often referred to in
> discussions
> about jumping statements. I do not claim nor do I condone that he was
> ever a "psycho professor". The excrement that usually goes on on this
> forum is well beneath his achievements.
>
> > Pattern matching was introduced in lot of languages, not because
> somebody
>
> Well, perhaps we should then consider pattern matching, rather than
> enhancing the switch we currently have. Chances are that pattern matching
> is not going to be an enhancement to switch and will not quite look like
> a switch.
>

I'd definitely like to see pattern matching explained and discussed in
detail. I think the masses are ready to receive word of it.

But however that pans out, and whatever the optimisation issues of it or
switch, I'd still like to be able to do something this:

// spaced keyword, new construct, implicitly breaks (as discussed many
times before)
for (;;) {
switch if ( c : get_key()) : alias the expression
{
    case 'A', 'B', 'C': // Let's rid operator comma or disable it here, or
whatever, but need a construct like this:
        if (changed_mind())
            break case; // break early, could be 'case break' if
necessary/preferred.
        whatever();
    case ((c >= 'a' && <= 'z' && ! some_other_condiition(c)) ||
(something_else()):
        whatever();
    case 'D', 'E', 'F':
        whatever();
        fallthrough;
    case 'G':
        int x = whatever(); // This is a block, no warning please.
    case 'Q':
        print("done\n");
        break; // loop
    case 'Z':
        whatever();
    default:
        doh();
}
} // for

I can't see why it's not possible to have all of this, we have plenty of
scope through introducing something new.
I'm perfectly happy to leave existing switch alone to get something
perfectly flexible if a little less than optimal.
If I want optimal, I'm ok being expected to pick another construct.

But whatever we tie this functionality to, I'd like something like this.

I don't see why can't / shouldn't we have such a thing?

--

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

<div dir=3D"ltr"><br><br>On Sunday, February 8, 2015 at 6:53:58 AM UTC+13, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;">On 7 February 2015 at =
19:35, mobi phil &lt;<a onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:"=
 target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"-ojtJ6uakKIJ">=
mo...@mobiphil.com</a>&gt; wrote:
<br>&gt;&gt; I think the apparent readability of switch is questionable. An=
ecdotal as
<br>&gt;&gt; it
<br>&gt;&gt; may be, I have for while treated switch as an indication of "h=
ere be bugs"
<br>&gt;&gt; and "here be a very indeterminate state machine that nobody ca=
n maintain".
<br>&gt; there are tons of anecdotes about constructs, my favorite one is w=
ith goto.
<br>&gt; Was afraid to touch goto for long years, believed this psycho prof=
essor at
<br>&gt; the university how harmful it would be. It is like do not touch mo=
torbikes
<br>
<br>I am fully aware of the fact that quite many people misunderstand what
<br>eg. Dijkstra wrote, or didn't even bother reading what he wrote and
<br>rather resorted
<br>to broken-phones-hearsay. I am not saying goto or switch are inherently
<br>bad, I'm just saying we shouldn't necessarily promote either of them.
<br>
<br>Btw, I mentioned Dijkstra just because he's often referred to in discus=
sions
<br>about jumping statements. I do not claim nor do I condone that he was
<br>ever a "psycho professor". The excrement that usually goes on on this
<br>forum is well beneath his achievements.
<br>
<br>&gt; Pattern matching was introduced in lot of languages, not because s=
omebody
<br>
<br>Well, perhaps we should then consider pattern matching, rather than
<br>enhancing the switch we currently have. Chances are that pattern matchi=
ng
<br>is not going to be an enhancement to switch and will not quite look lik=
e
<br>a switch.
<br></blockquote><div><br></div><div>I'd definitely like to see pattern mat=
ching explained and discussed in detail. I think the masses are ready to re=
ceive word of it.</div><div><br></div><div>But however that pans out, and w=
hatever the optimisation issues of it or switch, I'd still like to be able =
to do something this:</div><div><br></div><div>// spaced keyword, new const=
ruct, implicitly breaks (as discussed many times before)</div><div>for (;;)=
 {<br>switch if ( c : get_key()) : alias the expression<br>{<br>&nbsp;&nbsp=
;&nbsp; case 'A', 'B', 'C': // Let's rid operator&nbsp;comma or&nbsp;disabl=
e&nbsp;it here, or whatever, but need a construct like this:</div><div>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (changed_mind())</div><div>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break case; //=
 break early, could be 'case&nbsp;break' if necessary/preferred.<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; whatever();<br>&nbsp;&nbsp;&nbsp; case&=
nbsp;((c &gt;=3D 'a' &amp;&amp; &lt;=3D 'z' &amp;&amp; ! some_other_condiit=
ion(c)) || (something_else()):<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; whatever();<br>&nbsp;&nbsp;&nbsp; case 'D', 'E', 'F':<br>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; whatever();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; fallthrough;<br>&nbsp;&nbsp;&nbsp; case 'G':</div><div>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int x&nbsp;=3D whatever(); // This is a bl=
ock, no warning please.<br>&nbsp;&nbsp;&nbsp; case 'Q':<br>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; print("done\n");</div><div>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;break; // loop<br>&nbsp;&nbsp;&nbsp; case 'Z':<b=
r>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; whatever();<br>&nbsp;&nbsp;&nb=
sp; default:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; doh();<br>}</div=
><div>} // for</div><div><br></div><div>I can't see why it's not possible t=
o have all of this, we have plenty of scope&nbsp;through introducing someth=
ing new.</div><div><div>I'm perfectly happy to leave existing switch alone =
to get something perfectly flexible if a little less than optimal.</div><di=
v>If I want optimal, I'm ok being expected to pick another construct.</div>=
<div><br></div><div>But&nbsp;whatever we tie this functionality to,&nbsp;I'=
d like something like this.</div></div><div><br></div><div>I don't see why =
can't / shouldn't we have such a thing?</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_15_1998188888.1423428398616--
------=_Part_14_692010599.1423428398616--

.

--047d7bdc79e40f1cf6050e9a012b
Content-Type: text/plain; charset=UTF-8

have a look how Swift implements it (well, most of things are taken over
from other languages)

let someCharacter: Character = "e"
switch someCharacter {
case "a", "e", "i", "o", "u":
    println("\(someCharacter) is a vowel")
case "b", "c", "d", "f", "g", "h", "j", "k", "l", "m",
"n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z":
    println("\(someCharacter) is a consonant")
default:
    println("\(someCharacter) is not a vowel or a consonant")
}
// prints "e is a vowel"


https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html

google for pattern matching in swift switch statement for more complex
examples

--

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

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

<div dir=3D"ltr"><div>have a look how Swift implements it (well, most of th=
ings are taken over from other languages)</div><div><br></div><div>let some=
Character: Character =3D &quot;e&quot;</div><div>switch someCharacter {</di=
v><div>case &quot;a&quot;, &quot;e&quot;, &quot;i&quot;, &quot;o&quot;, &qu=
ot;u&quot;:</div><div>=C2=A0 =C2=A0 println(&quot;\(someCharacter) is a vow=
el&quot;)</div><div>case &quot;b&quot;, &quot;c&quot;, &quot;d&quot;, &quot=
;f&quot;, &quot;g&quot;, &quot;h&quot;, &quot;j&quot;, &quot;k&quot;, &quot=
;l&quot;, &quot;m&quot;,</div><div>&quot;n&quot;, &quot;p&quot;, &quot;q&qu=
ot;, &quot;r&quot;, &quot;s&quot;, &quot;t&quot;, &quot;v&quot;, &quot;w&qu=
ot;, &quot;x&quot;, &quot;y&quot;, &quot;z&quot;:</div><div>=C2=A0 =C2=A0 p=
rintln(&quot;\(someCharacter) is a consonant&quot;)</div><div>default:</div=
><div>=C2=A0 =C2=A0 println(&quot;\(someCharacter) is not a vowel or a cons=
onant&quot;)</div><div>}</div><div>// prints &quot;e is a vowel&quot;</div>=
<div><br></div><div><br></div><div><a href=3D"https://developer.apple.com/l=
ibrary/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Contro=
lFlow.html">https://developer.apple.com/library/ios/documentation/Swift/Con=
ceptual/Swift_Programming_Language/ControlFlow.html</a><br></div><div><br><=
/div><div>google for pattern matching in swift switch statement for more co=
mplex examples</div><div><br></div><div><br></div><div class=3D"gmail_extra=
">
</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 />

--047d7bdc79e40f1cf6050e9a012b--

.

--Apple-Mail=_D9B121E5-7082-4FB3-81A0-22B1566F5627
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Most pattern matching, including simple switch use-cases, can be done by pu=
tting the common part of the pattern in a lambda and using if-else.

auto matches =3D [ someCharacter ] ( std::string charSet )
    { return std::any_of( charSet.begin(), charSet.end(), someCharacter ); =
};

if ( matches( "aeiou" ) ) {
    std::cout << someCharacter << " is a vowel\n";
} else if ( matches( "bcdfghjklmnpqrstvwxyz" ) ) {
    std::cout << someCharacter << " is a consonant\n=E2=80=9D;
} else {
    std::cout << someCharacter << " is not a vowel or a consonant\n=E2=80=
=9D;
}

Perhaps what we really need is a standard function, std::make_equality_test=
 (perhaps call it std::make_case):

template< typename value_type >
auto make_case( value_type in_v ) {
    struct {
        value_type value;

        bool operator () ( value_type const & t ) { return t =3D=3D v; }
        bool operator () ( std::initializer_list< value_type > ts )
            { return std::find( ts.begin(), ts.end(), value ) !=3D ts.end()=
; }
    } ret{ std::move( in_v ) };
    return ret;
}

Demo: http://coliru.stacked-crooked.com/a/dc0677f1d27c7a00

> On 2015=E2=80=9302=E2=80=9309, at 5:04 AM, mobi phil <mobi@mobiphil.com> =
wrote:
>=20
> have a look how Swift implements it (well, most of things are taken over =
from other languages)
>=20
> let someCharacter: Character =3D "e"
> switch someCharacter {
> case "a", "e", "i", "o", "u":
>     println("\(someCharacter) is a vowel")
> case "b", "c", "d", "f", "g", "h", "j", "k", "l", "m",
> "n", "p", "q", "r", "s", "t", "v", "w", "x", "y", "z":
>     println("\(someCharacter) is a consonant")
> default:
>     println("\(someCharacter) is not a vowel or a consonant")
> }
> // prints "e is a vowel"
>=20
>=20
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Sw=
ift_Programming_Language/ControlFlow.html <https://developer.apple.com/libr=
ary/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFl=
ow.html>
>=20
> google for pattern matching in swift switch statement for more complex ex=
amples

Looks like it also offers functional-style deductive pattern matching, whic=
h is another ballgame.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_D9B121E5-7082-4FB3-81A0-22B1566F5627
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Mo=
st pattern matching, including simple&nbsp;<font face=3D"Courier" class=3D"=
">switch</font> use-cases, can be done by putting the common part of the pa=
ttern in a lambda and using if-else.</div><div class=3D""><br class=3D""></=
div><div class=3D""><font face=3D"Courier" class=3D"">auto matches =3D [ so=
meCharacter ] ( std::string charSet )</font></div><div class=3D""><font fac=
e=3D"Courier" class=3D"">&nbsp; &nbsp; { return std::any_of( charSet.begin(=
), charSet.end(), someCharacter ); };</font></div><div class=3D""><font fac=
e=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""><font =
face=3D"Courier" class=3D"">if ( matches( "aeiou" ) ) {</font></div><div cl=
ass=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std::cout &lt;&lt;=
 someCharacter &lt;&lt; " is a vowel\n";</font></div><div class=3D""><font =
face=3D"Courier" class=3D"">} else if ( matches( "bcdfghjklmnpqrstvwxyz" ) =
) {</font></div><div class=3D""><div class=3D""><font face=3D"Courier" clas=
s=3D"">&nbsp; &nbsp; std::cout &lt;&lt; someCharacter &lt;&lt; " is a conso=
nant\n=E2=80=9D;</font></div></div><div class=3D""><font face=3D"Courier" c=
lass=3D"">} else {</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">&nbsp; &nbsp; std::cout &lt;&lt; someCharacter &lt;&lt; " is not a vo=
wel or a consonant\n=E2=80=9D;</font></div><div class=3D""><font face=3D"Co=
urier" class=3D"">}</font></div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Perhaps what we really need is a standard function, <font face=3D=
"Courier" class=3D"">std::make_equality_test</font> (perhaps call it <font =
face=3D"Courier" class=3D"">std::make_case</font>):</div><div class=3D""><b=
r class=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">templa=
te&lt; typename value_type &gt;</font></div><div class=3D""><font face=3D"C=
ourier" class=3D"">auto make_case( value_type in_v ) {</font></div><div cla=
ss=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; struct {</font></di=
v><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &n=
bsp; value_type value;</font></div><div class=3D""><font face=3D"Courier" c=
lass=3D""><br class=3D""></font></div><div class=3D""><font face=3D"Courier=
" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; bool operator () ( value_type cons=
t &amp; t ) { return t =3D=3D v; }</font></div><div class=3D""><div class=
=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; bool op=
erator () ( std::initializer_list&lt; value_type &gt; ts )</font></div><div=
 class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; { return std::find( ts.begin(), ts.end(), value ) !=3D ts.end(=
); }</font></div></div><div class=3D""><font face=3D"Courier" class=3D"">&n=
bsp; &nbsp; } ret{ std::move( in_v ) };</font></div><div class=3D""><font f=
ace=3D"Courier" class=3D"">&nbsp; &nbsp; return ret;</font></div><div class=
=3D""><font face=3D"Courier" class=3D"">}</font></div><div class=3D""><br c=
lass=3D""></div><div class=3D"">Demo: <a href=3D"http://coliru.stacked-croo=
ked.com/a/dc0677f1d27c7a00" class=3D"">http://coliru.stacked-crooked.com/a/=
dc0677f1d27c7a00</a></div><div class=3D""><br class=3D""></div><div><blockq=
uote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=E2=80=9309=
, at 5:04 AM, mobi phil &lt;<a href=3D"mailto:mobi@mobiphil.com" class=3D""=
>mobi@mobiphil.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newli=
ne"><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">have a look=
 how Swift implements it (well, most of things are taken over from other la=
nguages)</div><div class=3D""><br class=3D""></div><div class=3D"">let some=
Character: Character =3D "e"</div><div class=3D"">switch someCharacter {</d=
iv><div class=3D"">case "a", "e", "i", "o", "u":</div><div class=3D"">&nbsp=
; &nbsp; println("\(someCharacter) is a vowel")</div><div class=3D"">case "=
b", "c", "d", "f", "g", "h", "j", "k", "l", "m",</div><div class=3D"">"n", =
"p", "q", "r", "s", "t", "v", "w", "x", "y", "z":</div><div class=3D"">&nbs=
p; &nbsp; println("\(someCharacter) is a consonant")</div><div class=3D"">d=
efault:</div><div class=3D"">&nbsp; &nbsp; println("\(someCharacter) is not=
 a vowel or a consonant")</div><div class=3D"">}</div><div class=3D"">// pr=
ints "e is a vowel"</div><div class=3D""><br class=3D""></div><div class=3D=
""><br class=3D""></div><div class=3D""><a href=3D"https://developer.apple.=
com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/C=
ontrolFlow.html" class=3D"">https://developer.apple.com/library/ios/documen=
tation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html</a><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">googl=
e for pattern matching in swift switch statement for more complex examples<=
/div></div></div></blockquote><div><br class=3D""></div></div>Looks like it=
 also offers functional-style deductive pattern matching, which is another =
ballgame.</body></html>

<p></p>

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

--Apple-Mail=_D9B121E5-7082-4FB3-81A0-22B1566F5627--

.

------=_Part_77_430524854.1423037423928
Content-Type: multipart/alternative;
 boundary="----=_Part_78_958814435.1423037423928"

------=_Part_78_958814435.1423037423928
Content-Type: text/plain; charset=UTF-8

Just throwing some thoughts in...  To solve the fall-through problem, what
if the fall-through also had to be deliberate?  For example, you *must* use
a "break;" or "continue;" keyword otherwise you get a warning (not an
error).

switch (some_type)
{
    case "foo":
        foo();
        break; // Normal break

    case "bar":
        bar();
        continue; // Signal a deliberate fall-through to the next case
using continue.

    case "something":
        something();

    case "something_else":  // Trigger warning here because there is no
deliberate break or continue keyword before this case.
        something_else();
        break;

    case "some": continue; // Show intentions with deliberate continue;
    case "thing:
        some();
        thing();
        break;

    case "foobar":
    default:        // I believe this case should still cause a warning.
        foobar();
        break;      // I believe omitting a break here at the end should
also trigger a warning for consistency, but isn't absolutely necessary.
}

Note: This does not break backward compatibility and it does not force
conformity. Also, a continue wouldn't actually output any code, but it does
provide a mechanism for detecting what could be a problem and the compiler
can then output a warning.

The warning message could read, "New 'case' was found without a deliberate
'break' or 'continue'."

Thoughts?

--

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

<div dir=3D"ltr">Just throwing some thoughts in... &nbsp;To solve the fall-=
through problem, what if the fall-through also had to be deliberate? &nbsp;=
For example, you *must* use a "break;" or "continue;" keyword otherwise you=
 get a warning (not an error).<div><br></div><div><div class=3D"prettyprint=
" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; bac=
kground-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">switch</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">some_type</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">case</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">"foo"</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; foo</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">// Normal break</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">"bar"</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; bar</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">continue</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// Signal a deliberate fall-through t=
o the next case using continue</span><span style=3D"color: rgb(136, 0, 0); =
font-family: Arial, Helvetica, sans-serif;">.</span></div><div class=3D"sub=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">"something"=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &=
nbsp; &nbsp; </span><span style=3D"color: rgb(0, 136, 0);"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">something</span></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"something_else"</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> &nbsp;</span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// Trigger warning here because there is no=
 deliberate break or continue keyword before this case.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: rgb(0, 136, 0);"><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">something_else</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">();</span></span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">break</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;<br></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; case "so=
me": continue; // Show intentions with deliberate continue;<br>&nbsp; &nbsp=
; case "thing:<br>&nbsp; &nbsp; &nbsp; &nbsp; some();<br>&nbsp; &nbsp; &nbs=
p; &nbsp; thing();<br>&nbsp; &nbsp; &nbsp; &nbsp; break;<br><br>&nbsp; &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">case</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #080;" class=3D"styled-by-prettify">"foobar"</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">default</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><font color=3D"#0000=
00"><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp=
; &nbsp; &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">// I believe this case should still cause a warning.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp; &nbsp; &nbsp;=
 foobar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">break</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">; &nbsp; &nbsp; &nbsp;// I believe omitting a break here at the end =
should also trigger a warning for consistency, but isn't absolutely necessa=
ry.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}<br></span><=
/div></code></div><br>Note: This does not break backward compatibility and =
it does not force conformity. Also, a continue wouldn't actually output any=
 code, but it does provide a mechanism for detecting what could be a proble=
m and the compiler can then output a warning.</div><div><br></div><div>The =
warning message could read, "New 'case' was found without a deliberate 'bre=
ak' or 'continue'."</div><div><br></div><div>Thoughts?</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_78_958814435.1423037423928--
------=_Part_77_430524854.1423037423928--

.

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

On 4 February 2015 at 02:10, Ron <rsn10100@gmail.com> wrote:

> Just throwing some thoughts in...  To solve the fall-through problem, what
> if the fall-through also had to be deliberate?  For example, you *must* use
> a "break;" or "continue;" keyword otherwise you get a warning (not an
> error).
> Note: This does not break backward compatibility
>

Yes. it does.

int a = 1;
while (a) {
    switch (b()) {
        case 0:
            continue;
        default:
            a = 0;
            break;
    };
};

Current C and C++ semantics:  the program loops until b() returns a
non-zero value.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On 4 February 2015 at 02:10, Ron <span dir=3D"ltr">&lt;<a =
href=3D"mailto:rsn10100@gmail.com" target=3D"_blank">rsn10100@gmail.com</a>=
&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Just throwing some thought=
s in...=C2=A0 To solve the fall-through problem, what if the fall-through a=
lso had to be deliberate?=C2=A0 For example, you *must* use a &quot;break;&=
quot; or &quot;continue;&quot; keyword otherwise you get a warning (not an =
error).<br><div>Note: This does not break backward compatibility </div></di=
v></blockquote><div><br></div><div>Yes. it does.<br><br></div><div>int a =
=3D 1;<br></div><div>while (a) {<br></div><div>=C2=A0=C2=A0=C2=A0 switch (b=
()) {<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case 0:<br>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 continue=
;<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default:<br></di=
v><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a=
 =3D 0;<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 break;<br></div><div>=C2=A0=C2=A0=C2=A0 };=C2=A0 <br></div>=
<div>};<br><br></div><div>Current C and C++ semantics:=C2=A0 the program lo=
ops until b() returns a non-zero value.<br></div></div>-- <br><div class=3D=
"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hre=
f=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.co=
m</a>&gt;=C2=A0 (847) 691-1404</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 />

--089e011766d3888d8b050eadbf45--

.

------=_Part_899_742363990.1423515661627
Content-Type: multipart/alternative;
 boundary="----=_Part_900_31590860.1423515661627"

------=_Part_900_31590860.1423515661627
Content-Type: text/plain; charset=UTF-8


>
> Just throwing some thoughts in...  To solve the fall-through problem, what
>> if the fall-through also had to be deliberate?  For example, you *must* use
>> a "break;" or "continue;" keyword otherwise you get a warning (not an
>> error).
>> Note: This does not break backward compatibility
>>
>
> Yes. it does.
>
> int a = 1;
> while (a) {
>     switch (b()) {
>         case 0:
>             continue;
>         default:
>             a = 0;
>             break;
>     };
> };
>

Yes, you are correct there.  I originally wanted to use a new keyword but
at the last minute decided to re-use a current one without thinking it
through.  Clang uses a non-standard method, [[clang::fallthrough]]; to
detect and warn about implicit fall through, so what about
turning "fallthrough;" into a standard keyword ?

--

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Just throwing some thoughts in...&nbsp; To solve the fall-through probl=
em, what if the fall-through also had to be deliberate?&nbsp; For example, =
you *must* use a "break;" or "continue;" keyword otherwise you get a warnin=
g (not an error).<br><div>Note: This does not break backward compatibility =
</div></div></blockquote><div><br></div><div>Yes. it does.<br><br></div><di=
v>int a =3D 1;<br></div><div>while (a) {<br></div><div>&nbsp;&nbsp;&nbsp; s=
witch (b()) {<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case=
 0:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c=
ontinue;<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; default:<=
br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; a =3D 0;<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; break;<br></div><div>&nbsp;&nbsp;&nbsp; };&nbsp; <br><=
/div><div>};<br></div></div></div></blockquote><div><br></div><div>Yes, you=
 are correct there. &nbsp;I originally wanted to use a new keyword but at t=
he last minute decided to re-use a current one without thinking it through.=
 &nbsp;Clang uses a non-standard method, [[clang::fallthrough]]; to detect =
and warn about implicit fall through, so what about turning&nbsp;"fallthrou=
gh;"&nbsp;into a standard keyword ?</div><div><br></div></div>

<p></p>

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

.

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

On 9 February 2015 at 15:01, Ron <rsn10100@gmail.com> wrote:

> so what about turning "fallthrough;" into a standard keyword ?


That breaks both backwards compatibility and C compatibility.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 9 February 2015 at 15:01, Ro=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:rsn10100@gmail.com" target=3D"_bl=
ank">rsn10100@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"> so what about turning=C2=A0&quot;fallthrou=
gh;&quot;=C2=A0into a standard keyword ?</blockquote></div><br>That breaks =
both backwards compatibility and C compatibility.</div><div class=3D"gmail_=
extra">-- <br><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>&gt;=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404=
" target=3D"_blank">(847) 691-1404</a></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 />

--001a11c3c082ce4d7c050eae500b--

.

On Mon, Feb 09, 2015 at 01:01:01PM -0800, Ron wrote:
>
> >
> > Just throwing some thoughts in...  To solve the fall-through problem, what
> >> if the fall-through also had to be deliberate?  For example, you *must* use
> >> a "break;" or "continue;" keyword otherwise you get a warning (not an
> >> error).
> >> Note: This does not break backward compatibility
> >>
> >
> > Yes. it does.
> >
> > int a = 1;
> > while (a) {
> >     switch (b()) {
> >         case 0:
> >             continue;
> >         default:
> >             a = 0;
> >             break;
> >     };
> > };
> >
>
> Yes, you are correct there.  I originally wanted to use a new keyword but
> at the last minute decided to re-use a current one without thinking it
> through.  Clang uses a non-standard method, [[clang::fallthrough]]; to
> detect and warn about implicit fall through, so what about
> turning "fallthrough;" into a standard keyword ?

The clang method - to use an attribute - is perfectly valid and I can't
see a reason for the standard to not accept a [[fallthrough]] attribute
that indicates that falling through the marked case statement is
expected.

Did anyone ever propose to simply add [[fallthrough]] or did all the "make a
better switch" proposals drift into the sky?

/MF

--

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

.

On 9 February 2015 at 23:56, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> Did anyone ever propose to simply add [[fallthrough]] or did all the "make a


I don't recall seeing a proposal for that. As I do a fair amount of
proposal tracking,
that means either
1) such a proposal didn't surface
2) such a proposal didn't surface
:D

--

---
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_4324_76816008.1423526676547
Content-Type: multipart/alternative;
 boundary="----=_Part_4325_408974609.1423526676547"

------=_Part_4325_408974609.1423526676547
Content-Type: text/plain; charset=UTF-8

I would vote against using an an attribute like [[fallthrough]].  It seems
to give a warning where it is not supported and wouldn't be very portable.
 The idea of getting a warning in places where the keyword is supposed to
suppress one breaks the idea for me.

How about making "fallthrough" a specially "defined" keyword so that it
would be possible to detect if it is supported by the compiler using the
pre-processor?  This way you can do the following for older compilers that
don't support it without breaking the code or getting warnings about
unknown attributes.

#include <iostream>
#include <string>

// 3 lines for platforms that don't support the fallthrough keyword
#ifndef fallthrough
#define fallthrough
#endif

int main()
{
for (int i = 0; i < 5; ++i)
{
switch (i)
{
case 0:
std::cout << "case 0.\n";
break;
case 1:
std::cout << "case 1.\n";
continue;
case 2:
std::cout << "case 2.\n";
[[fallthrough]]; // <- gives warning on compilers where its not supported.
BAD
case 3:
std::cout << "case 3.\n";
fallthrough;
default:
std::cout << "default.\n";
break;
}
}
std::cout << "done\n";
return 0;
}


Only 3 lines are necessary to compile freely on older compilers and you
won't get warnings about unknown attributes.  So backwards compatibility is
possible with this method and you still get the implicit fall through
warnings on compilers that do support it.  It is still ugly but better then
a non-portable attribute, it is still optional to use and could be better
then not having the implicit fall through warning at all.

--

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

<div dir=3D"ltr">I would vote against using an an attribute like [[fallthro=
ugh]]. &nbsp;It seems to give a warning where it is not supported and would=
n't be very portable. &nbsp;The idea of getting a warning in places where t=
he keyword is supposed to suppress one breaks the idea for me.<div><br></di=
v><div>How about making "fallthrough" a specially "defined" keyword so that=
 it would be possible to detect if it is supported by the compiler using th=
e pre-processor? &nbsp;This way you can do the following for older compiler=
s that don't support it without breaking the code or getting warnings about=
 unknown attributes.<div><br></div><div><div class=3D"prettyprint" style=3D=
"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-co=
lor: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><div class=3D"subprettyprint"><font color=3D"#660066">#include &lt=
;iostream&gt;</font></div><div class=3D"subprettyprint"><font color=3D"#660=
066">#include &lt;string&gt;</font></div><div class=3D"subprettyprint"><fon=
t color=3D"#660066"><br>// 3 lines for platforms that don't support the fal=
lthrough keyword</font></div><div class=3D"subprettyprint"><font color=3D"#=
660066">#ifndef fallthrough</font></div><div class=3D"subprettyprint"><font=
 color=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:pre"=
> </span>#define fallthrough</font></div><div class=3D"subprettyprint"><fon=
t color=3D"#660066">#endif</font></div><div class=3D"subprettyprint"><font =
color=3D"#660066"><br></font></div><div class=3D"subprettyprint"><font colo=
r=3D"#660066">int main()</font></div><div class=3D"subprettyprint"><font co=
lor=3D"#660066">{</font></div><div class=3D"subprettyprint"><font color=3D"=
#660066"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>f=
or (int i =3D 0; i &lt; 5; ++i)</font></div><div class=3D"subprettyprint"><=
font color=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:=
pre"> </span>{</font></div><div class=3D"subprettyprint"><font color=3D"#66=
0066"><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>swi=
tch (i)</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><=
span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>{</font></=
div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre">  </span>case 0:</font></div><div c=
lass=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-sp=
an" style=3D"white-space:pre">   </span>std::cout &lt;&lt; "case 0.\n";</fo=
nt></div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">   </span>break;</font></div>=
<div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-=
tab-span" style=3D"white-space:pre">  </span>case 1:</font></div><div class=
=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">   </span>std::cout &lt;&lt; "case 1.\n";</font><=
/div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"A=
pple-tab-span" style=3D"white-space:pre">   </span>continue;</font></div><d=
iv class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-ta=
b-span" style=3D"white-space:pre">  </span>case 2:</font></div><div class=
=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">   </span>std::cout &lt;&lt; "case 2.\n";</font><=
/div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"A=
pple-tab-span" style=3D"white-space:pre">   </span>[[fallthrough]]; // &lt;=
- gives warning on compilers where its not supported. BAD</font></div><div =
class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-s=
pan" style=3D"white-space: pre;">  </span>case 3:</font></div><div class=3D=
"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" sty=
le=3D"white-space: pre;">   </span>std::cout &lt;&lt; "case 3.\n";</font></=
div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Ap=
ple-tab-span" style=3D"white-space: pre;">   </span>fallthrough;</font></di=
v><div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Appl=
e-tab-span" style=3D"white-space:pre">  </span>default:</font></div><div cl=
ass=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-spa=
n" style=3D"white-space:pre">   </span>std::cout &lt;&lt; "default.\n";</fo=
nt></div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre">   </span>break;</font></div>=
<div class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-=
tab-span" style=3D"white-space:pre">  </span>}</font></div><div class=3D"su=
bprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>}</font></div><div class=3D"subprettyprint"><f=
ont color=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:p=
re"> </span>std::cout &lt;&lt; "done\n";</font></div><div class=3D"subprett=
yprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" style=3D"whi=
te-space:pre"> </span>return 0;</font></div><div class=3D"subprettyprint"><=
font color=3D"#660066">}</font></div><div><br></div></div></code></div><br>=
Only 3 lines are necessary to compile freely on older compilers and you won=
't get warnings about unknown attributes. &nbsp;So backwards compatibility =
is possible with this method and you still get the implicit fall through wa=
rnings on compilers that do support it. &nbsp;It is still ugly but better t=
hen a non-portable attribute, it is still optional to use and could be bett=
er then not having the implicit fall through warning at all.</div></div></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_4325_408974609.1423526676547--
------=_Part_4324_76816008.1423526676547--

.

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

On Mon, Feb 9, 2015 at 4:04 PM, Ron <rsn10100@gmail.com> wrote:

> I would vote against using an an attribute like [[fallthrough]].  It seems
> to give a warning where it is not supported and wouldn't be very portable.
> The idea of getting a warning in places where the keyword is supposed to
> suppress one breaks the idea for me.
>
> How about making "fallthrough" a specially "defined" keyword so that it
> would be possible to detect if it is supported by the compiler using the
> pre-processor?
>

SG10's latest draft for SD-6 includes a preprocessor macro that you can use
to detect the existence of an attribute:

#if __has_cpp_attribute(fallthrough)
#define fallthrough [[fallthrough]]
#else
#define fallthrough
#endif


> This way you can do the following for older compilers that don't support
> it without breaking the code or getting warnings about unknown attributes.
>
> #include <iostream>
> #include <string>
>
> // 3 lines for platforms that don't support the fallthrough keyword
> #ifndef fallthrough
> #define fallthrough
> #endif
>
> int main()
> {
> for (int i = 0; i < 5; ++i)
> {
> switch (i)
> {
> case 0:
> std::cout << "case 0.\n";
> break;
> case 1:
> std::cout << "case 1.\n";
> continue;
> case 2:
> std::cout << "case 2.\n";
> [[fallthrough]]; // <- gives warning on compilers where its not supported.
> BAD
> case 3:
> std::cout << "case 3.\n";
> fallthrough;
> default:
> std::cout << "default.\n";
> break;
> }
> }
> std::cout << "done\n";
> return 0;
> }
>
>
> Only 3 lines are necessary to compile freely on older compilers and you
> won't get warnings about unknown attributes.  So backwards compatibility is
> possible with this method and you still get the implicit fall through
> warnings on compilers that do support it.  It is still ugly but better then
> a non-portable attribute, it is still optional to use and could be better
> then not having the implicit fall through warning at all.
>
> --
>
> ---
> 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/.

--089e0122eda0ffadcb050eb0e2c6
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, Feb 9, 2015 at 4:04 PM, Ron <span dir=3D"ltr">&lt;<a href=3D"mailto:rsn=
10100@gmail.com" target=3D"_blank">rsn10100@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I would vote against us=
ing an an attribute like [[fallthrough]].=C2=A0 It seems to give a warning =
where it is not supported and wouldn&#39;t be very portable.=C2=A0 The idea=
 of getting a warning in places where the keyword is supposed to suppress o=
ne breaks the idea for me.<div><br></div><div>How about making &quot;fallth=
rough&quot; a specially &quot;defined&quot; keyword so that it would be pos=
sible to detect if it is supported by the compiler using the pre-processor?=
</div></div></blockquote><div><br></div><div>SG10&#39;s latest draft for SD=
-6 includes a preprocessor macro that you can use to detect the existence o=
f an attribute:</div><div><br></div><div>#if __has_cpp_attribute(fallthroug=
h)</div><div>#define fallthrough [[fallthrough]]</div><div>#else</div><div>=
#define fallthrough</div><div>#endif</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>This way you can do the following for =
older compilers that don&#39;t support it without breaking the code or gett=
ing warnings about unknown attributes.<div><br></div><div><div style=3D"bor=
der:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(25=
0,250,250)"><code><div><div><font color=3D"#660066">#include &lt;iostream&g=
t;</font></div><div><font color=3D"#660066">#include &lt;string&gt;</font><=
/div><div><font color=3D"#660066"><br>// 3 lines for platforms that don&#39=
;t support the fallthrough keyword</font></div><div><font color=3D"#660066"=
>#ifndef fallthrough</font></div><div><font color=3D"#660066"><span style=
=3D"white-space:pre-wrap"> </span>#define fallthrough</font></div><div><fon=
t color=3D"#660066">#endif</font></div><div><font color=3D"#660066"><br></f=
ont></div><div><font color=3D"#660066">int main()</font></div><div><font co=
lor=3D"#660066">{</font></div><div><font color=3D"#660066"><span style=3D"w=
hite-space:pre-wrap"> </span>for (int i =3D 0; i &lt; 5; ++i)</font></div><=
div><font color=3D"#660066"><span style=3D"white-space:pre-wrap"> </span>{<=
/font></div><div><font color=3D"#660066"><span style=3D"white-space:pre-wra=
p">  </span>switch (i)</font></div><div><font color=3D"#660066"><span style=
=3D"white-space:pre-wrap">  </span>{</font></div><div><font color=3D"#66006=
6"><span style=3D"white-space:pre-wrap">  </span>case 0:</font></div><div><=
font color=3D"#660066"><span style=3D"white-space:pre-wrap">   </span>std::=
cout &lt;&lt; &quot;case 0.\n&quot;;</font></div><div><font color=3D"#66006=
6"><span style=3D"white-space:pre-wrap">   </span>break;</font></div><div><=
font color=3D"#660066"><span style=3D"white-space:pre-wrap">  </span>case 1=
:</font></div><div><font color=3D"#660066"><span style=3D"white-space:pre-w=
rap">   </span>std::cout &lt;&lt; &quot;case 1.\n&quot;;</font></div><div><=
font color=3D"#660066"><span style=3D"white-space:pre-wrap">   </span>conti=
nue;</font></div><div><font color=3D"#660066"><span style=3D"white-space:pr=
e-wrap">  </span>case 2:</font></div><div><font color=3D"#660066"><span sty=
le=3D"white-space:pre-wrap">   </span>std::cout &lt;&lt; &quot;case 2.\n&qu=
ot;;</font></div><div><font color=3D"#660066"><span style=3D"white-space:pr=
e-wrap">   </span>[[fallthrough]]; // &lt;- gives warning on compilers wher=
e its not supported. BAD</font></div><div><font color=3D"#660066"><span sty=
le=3D"white-space:pre-wrap">  </span>case 3:</font></div><div><font color=
=3D"#660066"><span style=3D"white-space:pre-wrap">   </span>std::cout &lt;&=
lt; &quot;case 3.\n&quot;;</font></div><div><font color=3D"#660066"><span s=
tyle=3D"white-space:pre-wrap">   </span>fallthrough;</font></div><div><font=
 color=3D"#660066"><span style=3D"white-space:pre-wrap">  </span>default:</=
font></div><div><font color=3D"#660066"><span style=3D"white-space:pre-wrap=
">   </span>std::cout &lt;&lt; &quot;default.\n&quot;;</font></div><div><fo=
nt color=3D"#660066"><span style=3D"white-space:pre-wrap">   </span>break;<=
/font></div><div><font color=3D"#660066"><span style=3D"white-space:pre-wra=
p">  </span>}</font></div><div><font color=3D"#660066"><span style=3D"white=
-space:pre-wrap"> </span>}</font></div><div><font color=3D"#660066"><span s=
tyle=3D"white-space:pre-wrap"> </span>std::cout &lt;&lt; &quot;done\n&quot;=
;</font></div><div><font color=3D"#660066"><span style=3D"white-space:pre-w=
rap"> </span>return 0;</font></div><div><font color=3D"#660066">}</font></d=
iv><div><br></div></div></code></div><br>Only 3 lines are necessary to comp=
ile freely on older compilers and you won&#39;t get warnings about unknown =
attributes.=C2=A0 So backwards compatibility is possible with this method a=
nd you still get the implicit fall through warnings on compilers that do su=
pport it.=C2=A0 It is still ugly but better then a non-portable attribute, =
it is still optional to use and could be better then not having the implici=
t fall through warning at all.</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></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 />

--089e0122eda0ffadcb050eb0e2c6--

.

--Apple-Mail=_E71558BA-DA7D-4913-B68D-308EBC589403
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9310, at 8:22 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>=20
> SG10's latest draft for SD-6 includes a preprocessor macro that you can u=
se to detect the existence of an attribute:
>=20
> #if __has_cpp_attribute(fallthrough)
> #define fallthrough [[fallthrough]]
> #else
> #define fallthrough
> #endif

Ugh. Weren=E2=80=99t attributes designed to prevent that problem in the fir=
st place?

The whole point is that there shouldn=E2=80=99t be a warning for unknown at=
tributes. They=E2=80=99re merely comments that can help the compiler.

Here we have an attribute which disables a warning. If you disable the attr=
ibute, you=E2=80=99ll get a warning. If your stupid compiler complains that=
 it can=E2=80=99t read all the attribute-comments, then you get two warning=
s.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_E71558BA-DA7D-4913-B68D-308EBC589403
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9310, at 8:22 AM, Richard Smith &lt;<a href=3D"mailto:richard@metafo=
o.co.uk" class=3D"">richard@metafoo.co.uk</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" style=3D"font-f=
amily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal=
; font-weight: normal; letter-spacing: normal; line-height: normal; orphans=
: auto; text-align: start; text-indent: 0px; text-transform: none; white-sp=
ace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0p=
x;" class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div c=
lass=3D"">SG10's latest draft for SD-6 includes a preprocessor macro that y=
ou can use to detect the existence of an attribute:</div><div class=3D""><b=
r class=3D""></div><div class=3D"">#if __has_cpp_attribute(fallthrough)</di=
v><div class=3D"">#define fallthrough [[fallthrough]]</div><div class=3D"">=
#else</div><div class=3D"">#define fallthrough</div><div class=3D"">#endif<=
/div></div></div></div></div></blockquote><div><br class=3D""></div><div>Ug=
h. Weren=E2=80=99t attributes designed to prevent that problem in the first=
 place?</div><div><br class=3D""></div><div>The whole point is that there s=
houldn=E2=80=99t be a warning for unknown attributes. They=E2=80=99re merel=
y comments that can help the compiler.</div><div><br class=3D""></div><div>=
Here we have an attribute which disables a warning. If you disable the attr=
ibute, you=E2=80=99ll get a warning. If your stupid compiler complains that=
 it can=E2=80=99t read all the attribute-comments, then you get <i class=3D=
"">two</i>&nbsp;warnings.</div></div></body></html>

<p></p>

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

--Apple-Mail=_E71558BA-DA7D-4913-B68D-308EBC589403--

.

------=_Part_4264_1821831951.1423531346354
Content-Type: multipart/alternative;
 boundary="----=_Part_4265_436130784.1423531346358"

------=_Part_4265_436130784.1423531346358
Content-Type: text/plain; charset=UTF-8



On Monday, February 9, 2015 at 4:22:50 PM UTC-8, Richard Smith wrote:
>
> On Mon, Feb 9, 2015 at 4:04 PM, Ron <rsn1...@gmail.com <javascript:>>
> wrote:
>
>> I would vote against using an an attribute like [[fallthrough]].  It
>> seems to give a warning where it is not supported and wouldn't be very
>> portable.  The idea of getting a warning in places where the keyword is
>> supposed to suppress one breaks the idea for me.
>>
>> How about making "fallthrough" a specially "defined" keyword so that it
>> would be possible to detect if it is supported by the compiler using the
>> pre-processor?
>>
>
> SG10's latest draft for SD-6 includes a preprocessor macro that you can
> use to detect the existence of an attribute:
>
> #if __has_cpp_attribute(fallthrough)
> #define fallthrough [[fallthrough]]
> #else
> #define fallthrough
> #endif
>

But if "__has_cpp_attribute()" is not supported then you still get a
warning.  So what good is that ?

--

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

<div dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 4:22:50 PM UTC-8, R=
ichard Smith wrote:<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 class=3D"gmail_quote">On Mon, Feb 9, 2015 at 4:04 PM, Ron <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"9b8AmCgiK4EJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">rsn1.=
...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">I would vote against using an an attribute like [[fallthrough]].=
&nbsp; It seems to give a warning where it is not supported and wouldn't be=
 very portable.&nbsp; The idea of getting a warning in places where the key=
word is supposed to suppress one breaks the idea for me.<div><br></div><div=
>How about making "fallthrough" a specially "defined" keyword so that it wo=
uld be possible to detect if it is supported by the compiler using the pre-=
processor?</div></div></blockquote><div><br></div><div>SG10's latest draft =
for SD-6 includes a preprocessor macro that you can use to detect the exist=
ence of an attribute:</div><div><br></div><div>#if __has_cpp_attribute(<wbr=
>fallthrough)</div><div>#define fallthrough [[fallthrough]]</div><div>#else=
</div><div>#define fallthrough</div><div>#endif</div></div></div></blockquo=
te><div><br></div><div>But if "<span style=3D"font-family: arial, sans-seri=
f; font-size: 12.8000001907349px;">__has_cpp_attribute(</span><span style=
=3D"font-family: arial, sans-serif; font-size: 12.8000001907349px;">)" is n=
ot supported then you still get a warning. &nbsp;So what good is that ?</sp=
an></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_4265_436130784.1423531346358--
------=_Part_4264_1821831951.1423531346354--

.

Any "fallthrough" mechanism would need to be synchronised with the C
standards committee, IMO.

On 2/10/15, Ron <rsn10100@gmail.com> wrote:
>
>
> On Monday, February 9, 2015 at 4:22:50 PM UTC-8, Richard Smith wrote:
>>
>> On Mon, Feb 9, 2015 at 4:04 PM, Ron <rsn1...@gmail.com <javascript:>>
>> wrote:
>>
>>> I would vote against using an an attribute like [[fallthrough]].  It
>>> seems to give a warning where it is not supported and wouldn't be very
>>> portable.  The idea of getting a warning in places where the keyword is
>>> supposed to suppress one breaks the idea for me.
>>>
>>> How about making "fallthrough" a specially "defined" keyword so that it
>>> would be possible to detect if it is supported by the compiler using the
>>>
>>> pre-processor?
>>>
>>
>> SG10's latest draft for SD-6 includes a preprocessor macro that you can
>> use to detect the existence of an attribute:
>>
>> #if __has_cpp_attribute(fallthrough)
>> #define fallthrough [[fallthrough]]
>> #else
>> #define fallthrough
>> #endif
>>
>
> But if "__has_cpp_attribute()" is not supported then you still get a
> warning.  So what good is that ?
>
> --
>
> ---
> 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/.

.

Given two case labels with no intervening code, a [[fallthrough]]
attribute shouldn't be necessary.

On 2/10/15, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Any "fallthrough" mechanism would need to be synchronised with the C
> standards committee, IMO.
>
> On 2/10/15, Ron <rsn10100@gmail.com> wrote:
>>
>>
>> On Monday, February 9, 2015 at 4:22:50 PM UTC-8, Richard Smith wrote:
>>>
>>> On Mon, Feb 9, 2015 at 4:04 PM, Ron <rsn1...@gmail.com <javascript:>>
>>> wrote:
>>>
>>>> I would vote against using an an attribute like [[fallthrough]].  It
>>>> seems to give a warning where it is not supported and wouldn't be very
>>>> portable.  The idea of getting a warning in places where the keyword is
>>>> supposed to suppress one breaks the idea for me.
>>>>
>>>> How about making "fallthrough" a specially "defined" keyword so that it
>>>> would be possible to detect if it is supported by the compiler using
>>>> the
>>>>
>>>> pre-processor?
>>>>
>>>
>>> SG10's latest draft for SD-6 includes a preprocessor macro that you can
>>> use to detect the existence of an attribute:
>>>
>>> #if __has_cpp_attribute(fallthrough)
>>> #define fallthrough [[fallthrough]]
>>> #else
>>> #define fallthrough
>>> #endif
>>>
>>
>> But if "__has_cpp_attribute()" is not supported then you still get a
>> warning.  So what good is that ?
>>
>> --
>>
>> ---
>> 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/.

.

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

On 9 February 2015 at 21:30, Douglas Boffey <douglas.boffey@gmail.com>
wrote:

> Given two case labels with no intervening code, a [[fallthrough]]
> attribute shouldn't be necessary.
>

Unless you want to guard against accidental commenting:

case 1:
/*
    StandDown();
    break;
*/
case 2:
    LaunchTheMissiles();
    break;
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 9 February 2015 at 21:30, Douglas Boffey <span dir=3D"ltr">&lt;<a href=
=3D"mailto:douglas.boffey@gmail.com" target=3D"_blank">douglas.boffey@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":16=
d" class=3D"a3s" style=3D"overflow:hidden">Given two case labels with no in=
tervening code, a [[fallthrough]]<br>
attribute shouldn&#39;t be necessary.</div></blockquote><div><br></div><div=
>Unless you want to guard against accidental commenting:</div><div><br></di=
v><div>case 1:</div><div>/*</div><div>=C2=A0 =C2=A0 StandDown();</div><div>=
=C2=A0 =C2=A0 break;</div><div>*/</div><div>case 2:</div><div>=C2=A0 =C2=A0=
 LaunchTheMissiles();=C2=A0</div><div>=C2=A0 =C2=A0 break;</div></div>-- <b=
r><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &l=
t;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@=
eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</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 />

--089e0158ab6afef445050eb394a6--

.

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

On Mon, Feb 9, 2015 at 5:22 PM, Ron <rsn10100@gmail.com> wrote:

>
>
> On Monday, February 9, 2015 at 4:22:50 PM UTC-8, Richard Smith wrote:
>>
>> On Mon, Feb 9, 2015 at 4:04 PM, Ron <rsn1...@gmail.com> wrote:
>>
>>> I would vote against using an an attribute like [[fallthrough]].  It
>>> seems to give a warning where it is not supported and wouldn't be very
>>> portable.  The idea of getting a warning in places where the keyword is
>>> supposed to suppress one breaks the idea for me.
>>>
>>> How about making "fallthrough" a specially "defined" keyword so that it
>>> would be possible to detect if it is supported by the compiler using the
>>> pre-processor?
>>>
>>
>> SG10's latest draft for SD-6 includes a preprocessor macro that you can
>> use to detect the existence of an attribute:
>>
>> #if __has_cpp_attribute(fallthrough)
>> #define fallthrough [[fallthrough]]
>> #else
>> #define fallthrough
>> #endif
>>
>
> But if "__has_cpp_attribute()" is not supported then you still get a
> warning.  So what good is that ?
>

Are you really suggesting that we don't use a mechanism that part of the
C++ committee already has in its draft (__has_cpp_attribute) and instead
use a mechanism that hasn't yet been invented (your fallthrough
almost-keyword), because __has_cpp_attribute is not already supported by
all compilers?

--

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

--089e015383eca9013a050eb3bac2
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, Feb 9, 2015 at 5:22 PM, Ron <span dir=3D"ltr">&lt;<a href=3D"mailto:rsn=
10100@gmail.com" target=3D"_blank">rsn10100@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On Monday, Febr=
uary 9, 2015 at 4:22:50 PM UTC-8, Richard Smith wrote:<span class=3D""><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu=
ote">On Mon, Feb 9, 2015 at 4:04 PM, Ron <span dir=3D"ltr">&lt;<a rel=3D"no=
follow">rsn1...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">I would vote against using an an attribute like [[f=
allthrough]].=C2=A0 It seems to give a warning where it is not supported an=
d wouldn&#39;t be very portable.=C2=A0 The idea of getting a warning in pla=
ces where the keyword is supposed to suppress one breaks the idea for me.<d=
iv><br></div><div>How about making &quot;fallthrough&quot; a specially &quo=
t;defined&quot; keyword so that it would be possible to detect if it is sup=
ported by the compiler using the pre-processor?</div></div></blockquote><di=
v><br></div><div>SG10&#39;s latest draft for SD-6 includes a preprocessor m=
acro that you can use to detect the existence of an attribute:</div><div><b=
r></div><div>#if __has_cpp_attribute(<u></u>fallthrough)</div><div>#define =
fallthrough [[fallthrough]]</div><div>#else</div><div>#define fallthrough</=
div><div>#endif</div></div></div></blockquote><div><br></div></span><div>Bu=
t if &quot;<span style=3D"font-family:arial,sans-serif;font-size:12.8000001=
907349px">__has_cpp_attribute(</span><span style=3D"font-family:arial,sans-=
serif;font-size:12.8000001907349px">)&quot; is not supported then you still=
 get a warning.=C2=A0 So what good is that ?</span></div></div></blockquote=
><div><br></div><div>Are you really suggesting that we don&#39;t use a mech=
anism that part of the C++ committee already has in its draft (__has_cpp_at=
tribute) and instead use a mechanism that hasn&#39;t yet been invented (you=
r fallthrough almost-keyword), because __has_cpp_attribute is not already s=
upported by all compilers?</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 />

--089e015383eca9013a050eb3bac2--

.

------=_Part_4374_118789837.1423541453158
Content-Type: multipart/alternative;
 boundary="----=_Part_4375_1488482396.1423541453159"

------=_Part_4375_1488482396.1423541453159
Content-Type: text/plain; charset=UTF-8


On Monday, February 9, 2015 at 7:46:18 PM UTC-8, Richard Smith wrote:
>
> On Mon, Feb 9, 2015 at 5:22 PM, Ron <rsn1...@gmail.com <javascript:>>
> wrote:
>
>>
>>
>> On Monday, February 9, 2015 at 4:22:50 PM UTC-8, Richard Smith wrote:
>>>
>>> On Mon, Feb 9, 2015 at 4:04 PM, Ron <rsn1...@gmail.com> wrote:
>>>
>>>> I would vote against using an an attribute like [[fallthrough]].  It
>>>> seems to give a warning where it is not supported and wouldn't be very
>>>> portable.  The idea of getting a warning in places where the keyword is
>>>> supposed to suppress one breaks the idea for me.
>>>>
>>>> How about making "fallthrough" a specially "defined" keyword so that it
>>>> would be possible to detect if it is supported by the compiler using the
>>>> pre-processor?
>>>>
>>>
>>> SG10's latest draft for SD-6 includes a preprocessor macro that you can
>>> use to detect the existence of an attribute:
>>>
>>> #if __has_cpp_attribute(fallthrough)
>>> #define fallthrough [[fallthrough]]
>>> #else
>>> #define fallthrough
>>> #endif
>>>
>>
>> But if "__has_cpp_attribute()" is not supported then you still get a
>> warning.  So what good is that ?
>>
>
> Are you really suggesting that we don't use a mechanism that part of the
> C++ committee already has in its draft (__has_cpp_attribute) and instead
> use a mechanism that hasn't yet been invented (your fallthrough
> almost-keyword), because __has_cpp_attribute is not already supported by
> all compilers?
>

So __has_cpp_attribute() can help determine if a given attribute is
supported.  So how do you then determine if __has_cpp_attribute() is
supported in a standard way so you can guard against errors that arise on
compilers that do not support __has_cpp_attribute() (which is all of them
that I've tested so far) ?  So you guard against whether the fallthrough
attribute is supported using __has_cpp_attribute() and then you guard
against whether the __has_cpp_attribute() is supported?  So
__has_cpp_attribute() is neither functional (at present) or elegant.  It
may have been approved but that doesn't mean I have to like it.

The method I wrote is still easier to implement and work around with the
pre-processor since it is not relying on a pre-processor function to exist
and only checks if one does not exist.  If fallthrough is already defined
then do nothing, otherwise #define fallthrough to nothing.  Doesn't break
new code on old compilers and doesn't throw an error about a feature that
doesn't exist yet on those old compilers.

Please don't take any of that as me being hostile.  I'm just trying to make
my point clear.

--

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

<div dir=3D"ltr"><br>On Monday, February 9, 2015 at 7:46:18 PM UTC-8, Richa=
rd Smith 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><div class=3D"gmail_quote">On Mon, Feb 9, 2015 at 5:22 PM, Ron <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"9GSKbx51Fk0J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">rsn1=
....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><br><br>On Monday, February 9, 2015 at 4:22:50 PM UTC-8, Richar=
d Smith wrote:<span><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 class=3D"gmail_quote">On Mon, Feb 9, 2015 at 4:04 PM, Ron <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">rsn1...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I would vote against using=
 an an attribute like [[fallthrough]].&nbsp; It seems to give a warning whe=
re it is not supported and wouldn't be very portable.&nbsp; The idea of get=
ting a warning in places where the keyword is supposed to suppress one brea=
ks the idea for me.<div><br></div><div>How about making "fallthrough" a spe=
cially "defined" keyword so that it would be possible to detect if it is su=
pported by the compiler using the pre-processor?</div></div></blockquote><d=
iv><br></div><div>SG10's latest draft for SD-6 includes a preprocessor macr=
o that you can use to detect the existence of an attribute:</div><div><br><=
/div><div>#if __has_cpp_attribute(<u></u>fallthroug<wbr>h)</div><div>#defin=
e fallthrough [[fallthrough]]</div><div>#else</div><div>#define fallthrough=
</div><div>#endif</div></div></div></blockquote><div><br></div></span><div>=
But if "<span style=3D"font-family:arial,sans-serif;font-size:12.8000001907=
349px">__has_cpp_attribute(</span><span style=3D"font-family:arial,sans-ser=
if;font-size:12.8000001907349px">)" is not supported then you still get a w=
arning.&nbsp; So what good is that ?</span></div></div></blockquote><div><b=
r></div><div>Are you really suggesting that we don't use a mechanism that p=
art of the C++ committee already has in its draft (__has_cpp_attribute) and=
 instead use a mechanism that hasn't yet been invented (your fallthrough al=
most-keyword), because __has_cpp_attribute is not already supported by all =
compilers?</div></div></div></div></blockquote><div><br></div><div>So __has=
_cpp_attribute() can help determine if a given attribute is supported. &nbs=
p;So how do you then determine if __has_cpp_attribute() is supported in a s=
tandard way so you can guard against errors that arise on compilers that do=
 not support __has_cpp_attribute() (which is all of them that I've tested s=
o far) ? &nbsp;So you guard against whether the fallthrough attribute is su=
pported using __has_cpp_attribute() and then you guard against whether the =
__has_cpp_attribute() is supported? &nbsp;So __has_cpp_attribute() is neith=
er functional (at present) or elegant. &nbsp;It may have been approved but =
that doesn't mean I have to like it.</div><div><br></div><div>The method I =
wrote is still easier to implement and work around with the pre-processor s=
ince it is not relying on a pre-processor function to exist and only checks=
 if one does not exist. &nbsp;If fallthrough is already defined then do not=
hing, otherwise #define fallthrough to nothing. &nbsp;Doesn't break new cod=
e on old compilers and doesn't throw an error about a feature that doesn't =
exist yet on those old compilers.</div><div><br></div><div>Please don't tak=
e any of that as me being hostile. &nbsp;I'm just trying to make my point c=
lear.</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_4375_1488482396.1423541453159--
------=_Part_4374_118789837.1423541453158--

.

On Monday 09 February 2015 20:10:53 Ron wrote:
> So __has_cpp_attribute() can help determine if a given attribute is
> supported.  So how do you then determine if __has_cpp_attribute() is
> supported in a standard way so you can guard against errors that arise on
> compilers that do not support __has_cpp_attribute() (which is all of them
> that I've tested so far) ?

Like this:
#ifndef __has_cpp_attribute
#  define__has_cpp_attribute(x)  0
#endif

This works with GCC 5 and Clang 3.6.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_B2FA2277-A52B-423D-B801-3EF24EFE533C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9310, at 12:10 PM, Ron <rsn10100@gmail.com <mail=
to:rsn10100@gmail.com>> wrote:
>=20
> So __has_cpp_attribute() can help determine if a given attribute is suppo=
rted.  So how do you then determine if __has_cpp_attribute() is supported i=
n a standard way

#if __cplusplus && __cplusplus > 201402

Thiago=E2=80=99s suggestion depends on an implementation using a predefined=
 function-like macro. I don=E2=80=99t have the spec on hand (I=E2=80=99m no=
t clear on the standardization status at all; did it go from SG10 all the w=
ay into a draft IS working paper after N4296?), but it might not be reliabl=
e.

> The method I wrote is still easier to implement and work around with the =
pre-processor since it is not relying on a pre-processor function to exist =
and only checks if one does not exist.

You suggested a keyword, but the preprocessor doesn=E2=80=99t know about ke=
ywords. It knows about macros. (Given __has_cpp_attribute(), it also knows =
about attributes.)

A macro doesn=E2=80=99t know the difference between a __fallthrough keyword=
 and a [[fallthrough]] attribute. So if you still want the fallthrough macr=
o to be standardized, it=E2=80=99s no worse off for the existence of those =
other things=E2=80=A6

>  If fallthrough is already defined then do nothing, otherwise #define fal=
lthrough to nothing.  Doesn't break new code on old compilers and doesn't t=
hrow an error about a feature that doesn't exist yet on those old compilers=
..

But it would break old code on new compilers.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_B2FA2277-A52B-423D-B801-3EF24EFE533C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"><meta http-equiv=3D"Content-Type" content=3D"text/html charset=3D=
utf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: spac=
e; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><div c=
lass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=
=80=9302=E2=80=9310, at 12:10 PM, Ron &lt;<a href=3D"mailto:rsn10100@gmail.=
com" class=3D"">rsn10100@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><div dir=3D"ltr" style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" cla=
ss=3D"">So __has_cpp_attribute() can help determine if a given attribute is=
 supported. &nbsp;So how do you then determine if __has_cpp_attribute() is =
supported in a standard way</div></div></blockquote><div class=3D""><br cla=
ss=3D""></div><div class=3D""><font face=3D"Courier" class=3D"">#if __cplus=
plus &amp;&amp; __cplusplus &gt; 201402</font></div><div class=3D""><br cla=
ss=3D""></div>Thiago=E2=80=99s suggestion depends on an implementation usin=
g a predefined function-like macro. I don=E2=80=99t have the spec on hand (=
I=E2=80=99m not clear on the standardization status at all; did it go from =
SG10 all the way into a draft IS working paper after N4296?), but it might =
not be reliable.</div><div class=3D""><br class=3D""><blockquote type=3D"ci=
te" class=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size:=
 12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D=
"">The method I wrote is still easier to implement and work around with the=
 pre-processor since it is not relying on a pre-processor function to exist=
 and only checks if one does not exist.</div></div></blockquote><div class=
=3D""><br class=3D""></div><div class=3D"">You suggested a keyword, but the=
 preprocessor doesn=E2=80=99t know about keywords. It knows about macros. (=
Given <font face=3D"Courier" class=3D"">__has_cpp_attribute()</font>, it al=
so knows about attributes.)</div><div class=3D""><br class=3D""></div><div =
class=3D"">A macro doesn=E2=80=99t know the difference between a <font face=
=3D"Courier" class=3D"">__fallthrough</font> keyword and a <font face=3D"Co=
urier" class=3D"">[[fallthrough]]</font> attribute. So if you still want th=
e <font face=3D"Courier" class=3D"">fallthrough</font> macro to be standard=
ized, it=E2=80=99s no worse off for the existence of those other things=E2=
=80=A6</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 12px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing=
: normal; line-height: normal; orphans: auto; text-align: start; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: auto; word-spaci=
ng: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D""> &nbsp=
;If fallthrough is already defined then do nothing, otherwise #define fallt=
hrough to nothing. &nbsp;Doesn't break new code on old compilers and doesn'=
t throw an error about a feature that doesn't exist yet on those old compil=
ers.</div></div></div></blockquote><br class=3D""></div><div class=3D"">But=
 it would break old code on new compilers.</div></body></html>

<p></p>

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

--Apple-Mail=_B2FA2277-A52B-423D-B801-3EF24EFE533C--

.

On Tuesday 10 February 2015 12:52:27 David Krauss wrote:
> Thiago=E2=80=99s suggestion depends on an implementation using a predefin=
ed
> function-like macro. I don=E2=80=99t have the spec on hand (I=E2=80=99m n=
ot clear on the
> standardization status at all; did it go from SG10 all the way into a dra=
ft
> IS working paper after N4296?), but it might not be reliable.

"The #ifdef and #ifndef directives, and the defined conditional inclusion=
=20
operator, shall treat __has_cpp_attribute as if it were the name of a defin=
ed=20
macro. The identifier __has_cpp_attribute shall not appear in any context n=
ot=20
mentioned in this section."

https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommenda=
tions#recs.hasattr

You could also test for an attribute that is in C++11 and required to be=20
supported by all compilers (that is, produce no error), like noreturn. But=
=20
writing:

#if __has_cpp_attribute(noreturn)

Without first checking for __has_cpp_attribute being defined can result in =
a=20
parsing error if it isn't. So you should really check that it is defined, f=
irst.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_3650_1765902159.1423546159466
Content-Type: multipart/alternative;
 boundary="----=_Part_3651_1293584773.1423546159466"

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


>
>
> You suggested a keyword, but the preprocessor doesn=E2=80=99t know about =
keywords.=20
> It knows about macros. (Given __has_cpp_attribute(), it also knows about=
=20
> attributes.)
>
> A macro doesn=E2=80=99t know the difference between a __fallthrough keywo=
rd and a=20
> [[fallthrough]] attribute. So if you still want the fallthrough macro to=
=20
> be standardized, it=E2=80=99s no worse off for the existence of those oth=
er things=E2=80=A6
>

#ifndef __has_cpp_attribute
    #define __has_cpp_attribute(x) 0
#endif


#if __has_cpp_attribute(fallthrough)
    #define fallthrough [[fallthrough]]
#else
    #define fallthrough
#endif

This does work.  What I suggested was a specially "defined" keyword=20
(pre-processor).  Something so that it would be possible for the=20
pre-processor to detect a keyword with fewer lines, but that would require=
=20
a compiler change.  And I guess it doesn't really matter how it's done as=
=20
long as everything works.


But it would break old code on new compilers.
>
 It wouldn't really break old code on new compilers, it would just warn=20
about it where necessary and only when the warning is enabled.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word"><div><div><br></div><div>You suggested a keyword, bu=
t the preprocessor doesn=E2=80=99t know about keywords. It knows about macr=
os. (Given <font face=3D"Courier">__has_cpp_attribute()</font>, it also kno=
ws about attributes.)</div><div><br></div><div>A macro doesn=E2=80=99t know=
 the difference between a <font face=3D"Courier">__fallthrough</font> keywo=
rd and a <font face=3D"Courier">[[fallthrough]]</font> attribute. So if you=
 still want the <font face=3D"Courier">fallthrough</font> macro to be stand=
ardized, it=E2=80=99s no worse off for the existence of those other things=
=E2=80=A6</div></div></div></blockquote><div><br></div><div class=3D"pretty=
print" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word=
; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">#ifndef</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> __has_cpp_attribute<br></span><font color=3D"#000000"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp; </span></font><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">#define</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> __has_cpp_attribute</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">#endif</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">#if __has_cpp_attribute(fallthrough)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><font color=3D"#000000"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp; </span></f=
ont><span style=3D"color: #800;" class=3D"styled-by-prettify">#define</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> fallthrough </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">fallthrough</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">]]</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">#else</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><font color=3D"#000000"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp; </span>=
</font><span style=3D"color: #800;" class=3D"styled-by-prettify">#define</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> fallthrough<=
br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">#endif<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan></div></code></div><div>This does work. &nbsp;What I suggested was a sp=
ecially "defined" keyword (pre-processor). &nbsp;Something so that it would=
 be possible for the pre-processor to detect a keyword with fewer lines, bu=
t that would require a compiler change. &nbsp;And I guess it doesn't really=
 matter how it's done as long as everything works.</div><div><br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;"><div style=3D"word-wrap: break-word;">But it w=
ould break old code on new compilers.</div></blockquote><div>&nbsp;It would=
n't really break old code on new compilers, it would just warn about it whe=
re necessary and only when the warning is enabled.</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_3651_1293584773.1423546159466--
------=_Part_3650_1765902159.1423546159466--

.

--Apple-Mail=_FAE83B00-F2CB-44D0-9CE4-67A0ACA7A99A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9302=E2=80=9310, at 1:29 PM, Ron <rsn10100@gmail.com> wrote=
:
>=20
>  Something so that it would be possible for the pre-processor to detect a=
 keyword with fewer lines, but that would require a compiler change.  And I=
 guess it doesn't really matter how it's done as long as everything works.

You might be interested in the link that Thiago just shared.

>  It wouldn't really break old code on new compilers, it would just warn a=
bout it where necessary and only when the warning is enabled.

It would break old code that uses fallthrough as an identifier. Proposals g=
o to great lengths to avoid reserving new keywords, and macros are no bette=
r.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_FAE83B00-F2CB-44D0-9CE4-67A0ACA7A99A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9302=
=E2=80=9310, at 1:29 PM, Ron &lt;<a href=3D"mailto:rsn10100@gmail.com" clas=
s=3D"">rsn10100@gmail.com</a>&gt; wrote:</div><div class=3D""><div dir=3D"l=
tr" class=3D""></div></div></blockquote><blockquote type=3D"cite" class=3D"=
"><br class=3D""></blockquote><blockquote type=3D"cite" class=3D""><div cla=
ss=3D""><div dir=3D"ltr" class=3D""><div class=3D"">&nbsp;Something so that=
 it would be possible for the pre-processor to detect a keyword with fewer =
lines, but that would require a compiler change. &nbsp;And I guess it doesn=
't really matter how it's done as long as everything works.</div></div></di=
v></blockquote><div><br class=3D""></div><div>You might be interested in th=
e link that Thiago just shared.</div><br class=3D""><blockquote type=3D"cit=
e" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">&nbsp;It wouldn't=
 really break old code on new compilers, it would just warn about it where =
necessary and only when the warning is enabled.</div></div></blockquote><br=
 class=3D""></div><div>It would break old code that uses <font face=3D"Cour=
ier" class=3D"">fallthrough</font> as an identifier. Proposals go to great =
lengths to avoid reserving new keywords, and macros are no better.</div></b=
ody></html>

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

--Apple-Mail=_FAE83B00-F2CB-44D0-9CE4-67A0ACA7A99A--

.

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

Like others on here I too dislike the fall-through mechanism of the built-i=
n switch. This has been a big pain for most of the Legacy bugs in the syste=
ms I work with. However I do like the simplicity and readability of It.

I wonder if it is possible to create something like the following which wou=
ld put the ultimate control in the developers hands where it should be. Mos=
t constructs in c++ leave the ultimate control in the developers hands whil=
e making the defaults be the most common and safe versions. Therefore I wou=
ld suggest something like the following for syntax:-

safe_switch<COMPARATOR> (myVar)
{
case [expected_value]:
    // do something
    continue; // explicit fall-through
case_any { [expected_value_1], [expected_value_2] }:
    // do something else
default:
    // do something else
}

Here the COMPARATOR is used to compare myVar (which can then be any type at=
 all) to any possible cases. All case labels also double as implicit break =
statements, ensuring clean usage. For those that require the use of a fall-=
through then the continue keyword could be used to explicitly fall-through =
as desired. This way it would be clear and issue free by default. Whether t=
hat ultimately becomes an if...else if set remains up to the implementation=
, likewise with any optimisations. This idea would just be a clear and simp=
le way to explicitly write what we want without having to duplicate any cod=
e.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_5853_110875627.1423644021060--

.

------=_Part_6176_825421800.1423644388886
Content-Type: text/plain; charset=UTF-8

Another option instead of using the continue keyword as the fall-through could be a new keyword (which would have to be constexpr)
continue_as([continuation_expected_value]);
which would allow for jumping to any other block based on the value of the new expected value which could be determined at compile time and add the required GOTO implementation.

--

---
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_6176_825421800.1423644388886--

.

------=_Part_279_228356224.1423672984190
Content-Type: multipart/alternative;
 boundary="----=_Part_280_429779579.1423672984190"

------=_Part_280_429779579.1423672984190
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 11, 2015 at 12:46:28 AM UTC-8, Izzy Coding wrote:
>
> Another option instead of using the continue keyword as the fall-through
> could be a new keyword (which would have to be constexpr)
> continue_as([continuation_expected_value]);
> which would allow for jumping to any other block based on the value of the
> new expected value which could be determined at compile time and add the
> required GOTO implementation.


As was pointed out earlier, continue wouldn't work.  Since all we're trying
to do is disable a warning on implicit fallthrough I've grown to the idea
of using the attributes mentioned previously.  I just wish that something
like '__fallthrough' would be '#defined' automatically as an alternative to
detecting the attribute and defining it ourselves.

A lot of great information in the link posted so here it is again.
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#recs.hasattr

--

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

<div dir=3D"ltr">On Wednesday, February 11, 2015 at 12:46:28 AM UTC-8, Izzy=
 Coding wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Another option i=
nstead of using the continue keyword as the fall-through could be a new key=
word (which would have to be constexpr)
<br>continue_as([continuation_<wbr>expected_value]);
<br>which would allow for jumping to any other block based on the value of =
the new expected value which could be determined at compile time and add th=
e required GOTO implementation.</blockquote><div><br></div><div>As was poin=
ted out earlier, continue wouldn't work. &nbsp;Since all we're trying to do=
 is disable a warning on implicit fallthrough I've grown to the idea of usi=
ng the attributes mentioned previously. &nbsp;I just wish that something li=
ke '__fallthrough' would be '#defined' automatically as an alternative to d=
etecting the attribute and defining it ourselves.</div><div><br></div><div>=
A lot of great information in the link posted so here it is again.</div><di=
v>https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommen=
dations#recs.hasattr&nbsp;</div><div><br></div></div>

<p></p>

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

.

On 2015-02-11 03:46, Izzy Coding wrote:
> Another option instead of using the continue keyword as the
> fall-through could be a new keyword (which would have to be
> constexpr)
>
> continue_as([continuation_expected_value]);
>
> which would allow for jumping to any other block based on the value
> of the new expected value which could be determined at compile time
> and add the required GOTO implementation.

  continue case <expr>;

....go back to the top of the switch, using '<expr>' as the input
expression to the switch statement rather than whatever was there
before. No new keywords introduced, ability to use non-constexpr
expressions. Compilers would hopefully optimize the case where the
expression is constexpr into a goto (or even nothing if the code for the
next case immediately follows the current case).

IIRC people gripe about this requiring the compiler to look ahead before
it knows what the 'continue' means.

--
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_898_2134494856.1424125191838
Content-Type: multipart/alternative;
 boundary="----=_Part_899_740721657.1424125191838"

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



Le mercredi 11 f=C3=A9vrier 2015 09:40:21 UTC+1, Izzy Coding a =C3=A9crit :
>
> Like others on here I too dislike the fall-through mechanism of the=20
> built-in switch. This has been a big pain for most of the Legacy bugs in=
=20
> the systems I work with. However I do like the simplicity and readability=
=20
> of It.=20
>
> I wonder if it is possible to create something like the following which=
=20
> would put the ultimate control in the developers hands where it should be=
..=20
> Most constructs in c++ leave the ultimate control in the developers hands=
=20
> while making the defaults be the most common and safe versions. Therefore=
 I=20
> would suggest something like the following for syntax:-=20
>
> safe_switch<COMPARATOR> (myVar)=20
> {=20
> case [expected_value]:=20
>     // do something=20
>     continue; // explicit fall-through=20
> case_any { [expected_value_1], [expected_value_2] }:=20
>     // do something else=20
> default:=20
>     // do something else=20
> }=20
>
> Here the COMPARATOR is used to compare myVar (which can then be any type=
=20
> at all) to any possible cases. All case labels also double as implicit=20
> break statements, ensuring clean usage. For those that require the use of=
 a=20
> fall-through then the continue keyword could be used to explicitly=20
> fall-through as desired. This way it would be clear and issue free by=20
> default. Whether that ultimately becomes an if...else if set remains up t=
o=20
> the implementation, likewise with any optimisations. This idea would just=
=20
> be a clear and simple way to explicitly write what we want without having=
=20
> to duplicate any code.


Something like that have already been proposed. Search for "explicit=20
switch" on this forum, you should find threads about that.
Now to make things short :=20
- If I remeber well, I think Bjarne Stroustrup itself said about this that=
=20
we need new constructs like we need a hole in the head.
- While I agree him, I think avoiding to introduce new construct (like the=
=20
explicit switch was since it introduce the [*explicit switch*] keyword and=
=20
also new syntactics rules), this doesn't means that existing ones can't be=
=20
improved.

For example, the fallback problem could be solved through a "*goto case*"=
=20
statement, a little like what c# does. (At least it's my opinion, don't=20
know what other think about it).

Now about the original problem:
AFAICS, I see one solution to this, but it's quite complex and don't know=
=20
is this is something we really wants. But let's expose it anyway :=20
Every switch could be decomposed into a suite of if/else statements. So=20
when i write this:

switch(a) {
  case "abc":
    doAbc();
    break;
  case "xyz":
    doXyz();
    break;
  default:
    doWhatYouWant();
    break;
}

this could be rewritten in :
if(a =3D=3D "abc")
  doXyz();
else if(a =3D=3D "xyz")
  doXyz();
else
  doWhatYouWant();

Now we know that c++ has already the ability to overload operators, then=20
the above code make sense.
In other word, as long as a class overload the =3D=3D operator, it is possi=
ble=20
to rewritte any switch statement into a series of comparison and use this=
=20
operator.=20
From that point, using string literals into a switch statement becomes=20
possible. It will just be compiled as if it was written using if/else=20
statements.
The thing is that even if this is possible to achieve this, lots of=20
problems will probably arise from that. For example, will the compilers be=
=20
able to optimize this correctly?  I just don't know.

Also I don't know if making possible to use any kind of object into a=20
switch statement is really a good idea or not. All I know is that it seems=
=20
possible to me.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>Le mercredi 11 f=C3=A9vrier 2015 09:40:21 UTC+1, I=
zzy Coding a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
Like others on here I too dislike the fall-through mechanism of the built-i=
n switch. This has been a big pain for most of the Legacy bugs in the syste=
ms I work with. However I do like the simplicity and readability of It.
<br>
<br>I wonder if it is possible to create something like the following which=
 would put the ultimate control in the developers hands where it should be.=
 Most constructs in c++ leave the ultimate control in the developers hands =
while making the defaults be the most common and safe versions. Therefore I=
 would suggest something like the following for syntax:-
<br>
<br>safe_switch&lt;COMPARATOR&gt; (myVar)
<br>{
<br>case [expected_value]:
<br>&nbsp; &nbsp; // do something
<br>&nbsp; &nbsp; continue; // explicit fall-through
<br>case_any { [expected_value_1], [expected_value_2] }:
<br>&nbsp; &nbsp; // do something else
<br>default:
<br>&nbsp; &nbsp; // do something else
<br>}
<br>
<br>Here the COMPARATOR is used to compare myVar (which can then be any typ=
e at all) to any possible cases. All case labels also double as implicit br=
eak statements, ensuring clean usage. For those that require the use of a f=
all-through then the continue keyword could be used to explicitly fall-thro=
ugh as desired. This way it would be clear and issue free by default. Wheth=
er that ultimately becomes an if...else if set remains up to the implementa=
tion, likewise with any optimisations. This idea would just be a clear and =
simple way to explicitly write what we want without having to duplicate any=
 code.</blockquote><div><br>Something like that have already been proposed.=
 Search for "explicit switch" on this forum, you should find threads about =
that.<br>Now to make things short : <br>- If I remeber well, I think Bjarne=
 Stroustrup itself said about this that we need new <span class=3D"_Tyb"></=
span>constructs like we need a hole in the head.<br>- While I agree him, I =
think avoiding to introduce new construct (like the explicit switch was sin=
ce it introduce the [<i>explicit switch</i>] keyword and also new syntactic=
s rules), this doesn't means that existing ones can't be improved.<br><br>F=
or example, the fallback problem could be solved through a "<i>goto case</i=
>" statement, a little like what c# does. (At least it's my opinion, don't =
know what other think about it).<br><br>Now about the original problem:<br>=
AFAICS, I see one solution to this, but it's quite complex and don't know i=
s this is something we really wants. But let's expose it anyway : <br>Every=
 switch could be decomposed into a suite of if/else statements. So when i w=
rite this:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">switch</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">&nbsp; case</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify">"abc"</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><c=
ode class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify"></span></code>doAbc</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">break</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">&nbsp; case</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"xy=
z"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypr=
int"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp=
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify"></span><=
/code>doXyz</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy"></span></code>break</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">&n=
bsp; default</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy"></span></code>doWhatYouWant</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify"></span></code>break</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span></div></code></div><br>this could be rewritten in=
 :<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">if</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">a </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"abc"</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp; doXyz</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">else</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">a </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify">"xyz"</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; doXyz</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">else</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; doWhatYouWant</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span></div></code></div><br>Now we know that c++ =
has already the ability to overload operators, then the above code make sen=
se.<br>In other word, as long as a class overload the =3D=3D operator, it i=
s possible to rewritte any switch statement into a series of comparison and=
 use this operator. <br>From that point, using string literals into a switc=
h statement becomes possible. It will just be compiled as if it was written=
 using if/else statements.<br>The thing is that even if this is possible to=
 achieve this, lots of problems will probably arise from that. For example,=
 will the compilers be able to optimize this correctly?&nbsp; I just don't =
know.<br><br>Also I don't know if making possible to use any kind of object=
 into a switch statement is really a good idea or not. All I know is that i=
t seems possible to me. <br></div></div>

<p></p>

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

.