------=_Part_564_1279731015.1434739817000
Content-Type: multipart/alternative;
 boundary="----=_Part_565_1390444400.1434739817000"

------=_Part_565_1390444400.1434739817000
Content-Type: text/plain; charset=UTF-8

Extend the syntax for switch statements to allow complex types to be used
too.

Switch statements are nice for when there is a lot of similar objects that
need to be compared. Other programing languages allow this to varying
extents, the most common addition to integers is languages with a string
type allowing switching on strings.

However, C++ does not allow this. This leads to ugly if statement trees to
do the exact same thing. The switch statement was supposed to be syntactic
sugar to avoid those!

What this would mean in practice is first allowing switch statements to
take expressions of any type. However, the case label needs a corresponding
change. It needs to be able to accept an expression of a comparable type to
the switch. This leads to two problems.

The first problem is "what is a comparable type?". The obvious answer is to
require there to be a matching operator== for the two types. But switch
statements are special, they are often implemented as jump tables. I do not
think it wise to prevent the compiler from doing similiar optimizations.
But at the same time, code needs to know which operators are required and
exactly which comparisons will be done and in what order. This is a problem
open for discussion.

The second problem is that not all case labels will be constexpr, some will
by its nature require runtime computation before the value is available.
This was not a problem with the if statement trees, since that was a free
form non-standard defined solution. I think that it may be a good idea to
loosen this requirement up to allow for normal expressions in case labels.

A third problem occurs when accounting for usability. Switch statements
with complex objects would be a prime target for string comparisons. String
literals do not compare as expected with character pointers. This is not a
new problem. I belive that this problem is best solved outside of the
standard by compilers providing warnings for when this is attempted.

Finally, a fourth problem occurs with types that have implicit type
conversion operators. I believe that the correct solution is to prioritize
the comparison operator(s) used. Otherwise cases like std::string vs string
literals would behave wrongly.

Here is an example of how this syntax would simplify code:

#include <string>
void setColor(int);
void setColor(std::string a) {

  switch(a) {
    case "green":
      setColor(0x00FF00);
    break;
    case "red":
      setColor(0xFF0000);
    break;
    case "blue":
      setColor(0x0000FF);
    break;
  }
}

Simple, easy to understand and the obvious solution.

--

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

<div dir=3D"ltr">Extend the syntax for switch statements to allow complex t=
ypes to be used too.<br><br>Switch statements are nice for when there is a =
lot of similar objects that need to be compared. Other programing languages=
 allow this to varying extents, the most common addition to integers is lan=
guages with a string type allowing switching on strings.<br><br>However, C+=
+ does not allow this. This leads to ugly if statement trees to do the exac=
t same thing. The switch statement was supposed to be syntactic sugar to av=
oid those!<br><br>What this would mean in practice is first allowing switch=
 statements to take expressions of any type. However, the case label needs =
a corresponding change. It needs to be able to accept an expression of a co=
mparable type to the switch. This leads to two problems.<br><br>The first p=
roblem is "what is a comparable type?". The obvious answer is to require th=
ere to be a matching operator=3D=3D for the two types. But switch statement=
s are special, they are often implemented as jump tables. I do not think it=
 wise to prevent the compiler from doing similiar optimizations. But at the=
 same time, code needs to know which operators are required and exactly whi=
ch comparisons will be done and in what order. This is a problem open for d=
iscussion.<br><br>The second problem is that not all case labels will be co=
nstexpr, some will by its nature require runtime computation before the val=
ue is available. This was not a problem with the if statement trees, since =
that was a free form non-standard defined solution. I think that it may be =
a good idea to loosen this requirement up to allow for normal expressions i=
n case labels.<br><br>A third problem occurs when accounting for usability.=
 Switch statements with complex objects would be a prime target for string =
comparisons. String literals do not compare as expected with character poin=
ters. This is not a new problem. I belive that this problem is best solved =
outside of the standard by compilers providing warnings for when this is at=
tempted.<br><br>Finally, a fourth problem occurs with types that have impli=
cit type conversion operators. I believe that the correct solution is to pr=
ioritize the comparison operator(s) used. Otherwise cases like std::string =
vs string literals would behave wrongly.<br><br>Here is an example of how t=
his syntax would simplify code:<br><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">#include</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">&lt;string&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> setColor</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</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">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> setColor</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">switch</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">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify">"green"</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; &nbsp; &nbsp; setColor</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0x00FF00</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">break</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">"red"</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; s=
etColor</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">0xFF0000</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">break</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify">"blue"</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; setColor</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">0x0000FF</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; </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></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br>Simple, easy to understand and the obvi=
ous solution.<br><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_565_1390444400.1434739817000--
------=_Part_564_1279731015.1434739817000--

.

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

Although I agree in principal this has been discussed many times before.
Most people would suggest that the switch syntax with its (in some cases ba=
d) fall through semantics is not an ideal feature to start with. Also no on=
e seems to believe there is a need for an extra semantic syntax in the lang=
uage when an if set would suffice and ultimately offers no optimisation ove=
r any form of switch.

Having said that I personally agree that from a coding point of view it wou=
ld be more easily read and would provide a cleaner interface.

I would say that given we are now in an era of modern c++, the limitations =
of the case labels should be explicitly comparable (either by being the cor=
rect type or to be convertible via an explicit constructor / assignment ope=
rator)

I would also suggest that the switch expression be able to accept any funct=
ional expression (e.g. Lamda function).

I would also suggest providing a comma operator to the case keyword to allo=
w multiple options for each block and do away with the fall through ability=
 (which could be implemented if required using goto).

Ultimately I would imply that the best possible implementation for this new=
 switch semantic would be most optimal when all cases are constexpr and can=
 be made jump tables at compile time. However, there should probably be a l=
evel 4 warning for any non constexpr expressions in case labels to warn abo=
ut possible runtime overheads.

--=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_877_1456355144.1434754191991--

.

On 2015-06-19 20:50, henke@henke37.cjb.net wrote:
> Extend the syntax for switch statements to allow complex types to be
> used too.
>
> Switch statements are nice for when there is a lot of similar objects
> that need to be compared. Other programing languages allow this to
> varying extents, the most common addition to integers is languages with
> a string type allowing switching on strings.
>
> [snip]
>
> Here is an example of how this syntax would simplify code:
>
> |
> #include<string>
> void setColor(int);
> void setColor(std::string a){
>
> switch(a){
> case "green":
>        setColor(0x00FF00);
> break;
> case "red":
>        setColor(0xFF0000);
> break;
> case "blue":
>        setColor(0x0000FF);
> break;
> }
> }
> |
>
> Simple, easy to understand and the obvious solution.
>

The code can be even more simpilied using a helper structure:

#include<string>
#include<map>

std::map<std::string, int> ColorMap =
    {{"green", 0x00FF00}, {"red", 0xFF0000}, {"blue", 0x0000FF}};

void setColor(int);

void setColor(std::string a)
{ setColor(ColorMap[a]); }


Likely with a peformance similar to what an extended switch statement
would have.


Bo Persson


--

---
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 Saturday 20 June 2015 11:35:55 Bo Persson wrote:
> std::map<std::string, int> ColorMap =
>     {{"green", 0x00FF00}, {"red", 0xFF0000}, {"blue", 0x0000FF}};
>
> void setColor(int);
>
> void setColor(std::string a)
> { setColor(ColorMap[a]); }
>
>
> Likely with a peformance similar to what an extended switch statement
> would have.

Are you including the cost of initialising that structure at load-time?
--
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/.

.

On 2015-06-20 18:36, Thiago Macieira wrote:
> On Saturday 20 June 2015 11:35:55 Bo Persson wrote:
>> std::map<std::string, int> ColorMap =
>>      {{"green", 0x00FF00}, {"red", 0xFF0000}, {"blue", 0x0000FF}};
>>
>> void setColor(int);
>>
>> void setColor(std::string a)
>> { setColor(ColorMap[a]); }
>>
>>
>> Likely with a peformance similar to what an extended switch statement
>> would have.
>
> Are you including the cost of initialising that structure at load-time?
>

Yes. I also assume the setColor function will be used multiple times
during the program execution.


Bo Persson


--

---
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=_5CA2FF9A-47C3-429D-9B5B-17DCB2B01C5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9320, at 2:50 AM, henke@henke37.cjb.net wrote:
>=20
> Simple, easy to understand and the obvious solution.

switch with a break in every case is a habitual solution, but it=E2=80=99s =
not very good. It=E2=80=99s better to forget switch and progress to somethi=
ng without fallthrough, like if-else or std::map.


> On 2015=E2=80=9306=E2=80=9321, at 12:36 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> Are you including the cost of initialising that structure at load-time?


It could use char* instead of std::string. With predynamic storage, the map=
 nodes could be statically initialized too.

--=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=_5CA2FF9A-47C3-429D-9B5B-17DCB2B01C5B
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=9306=
=E2=80=9320, at 2:50 AM, <a href=3D"mailto:henke@henke37.cjb.net" class=3D"=
">henke@henke37.cjb.net</a> wrote:</div><br class=3D"Apple-interchange-newl=
ine"><div class=3D""><span style=3D"font-family: Helvetica; font-size: 12px=
; font-style: normal; font-variant: normal; font-weight: normal; letter-spa=
cing: normal; line-height: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !=
important;" class=3D"">Simple, easy to understand and the obvious solution.=
</span><br style=3D"font-family: Helvetica; font-size: 12px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;" class=3D""></div></blockquote></div><br class=
=3D""><div class=3D""><font face=3D"Courier" class=3D"">switch</font>&nbsp;=
with a <font face=3D"Courier" class=3D"">break</font> in every <font face=
=3D"Courier" class=3D"">case</font> is a habitual solution, but it=E2=80=99=
s not very good. It=E2=80=99s better to forget <font face=3D"Courier" class=
=3D"">switch</font> and progress to something without fallthrough, like if-=
else or&nbsp;<font face=3D"Courier" class=3D"">std::map</font>.</div><div c=
lass=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div cl=
ass=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=
=9306=E2=80=9321, at 12:36 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago=
@macieira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><span class=3D"" style=3D"fl=
oat: none; display: inline !important;">Are you including the cost of initi=
alising that structure at load-time?</span><br class=3D""></div></blockquot=
e></div><div class=3D""><div class=3D""><span class=3D"" style=3D"float: no=
ne; display: inline !important;"><br class=3D""></span></div></div><div cla=
ss=3D""><span class=3D"" style=3D"float: none; display: inline !important;"=
>It could use <font face=3D"Courier" class=3D"">char*</font> instead of <fo=
nt face=3D"Courier" class=3D"">std::string</font>. With predynamic storage,=
 the <font face=3D"Courier" class=3D"">map</font> nodes could be statically=
 initialized too.</span></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=_5CA2FF9A-47C3-429D-9B5B-17DCB2B01C5B--

.

--Apple-Mail=_CE82CA92-A23D-4AE3-86AA-96A813ED9F0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

How about a library solution?

template< typename operand, typename comparison =3D std::equal_to<> >
class bound_comparison {
    comparison c;
    operand o;
public:
    bound_comparison( operand && in_o, comparison in_c =3D {} )
        : o( std::forward< operand >( in_o ) ), c( std::move( in_c ) ) {}

    template< typename lhs >
    bool operator () ( lhs const & l ) const
        { return c( l, o ); }

    bool operator () ( std::initializer_list< std::decay_t< operand > > il =
) const
        { return std::find( il.begin(), il.end(), o ) !=3D il.end(); }

    std::decay_t< operand > const & get_value() const
        { return o; }
};

template< typename comparison =3D std::equal_to<>, typename operand >
bound_comparison< operand, comparison > bind_comparator( operand && o, comp=
arison c =3D {} )
    { return { std::forward< operand >( o ), std::move( c ) }; }


> On 2015=E2=80=9306=E2=80=9320, at 6:49 AM, Izzy Coding <matthew.i.greenwo=
od@gmail.com> wrote:
>=20
> I would say that given we are now in an era of modern c++, the limitation=
s of the case labels should be explicitly comparable (either by being the c=
orrect type or to be convertible via an explicit constructor / assignment o=
perator)

auto case_ =3D bind_comparator( std::cin.get() );
if ( case_( '-' ) ) {
    std::cout << "dash\n";
} else if ( c( 48 ) ) {
    std::cout << "nought\n";
}

> I would also suggest that the switch expression be able to accept any fun=
ctional expression (e.g. Lamda function).

Even better if no lambda is needed:

else if ( std::isspace( case_.get_value() ) ) {
    std::cout << "space out\n";
}

> I would also suggest providing a comma operator to the case keyword to al=
low multiple options for each block and do away with the fall through abili=
ty (which could be implemented if required using goto).

else if ( case_({ 'X', 'x' }) ) {
    std::cout << "equis\n";
}

> Ultimately I would imply that the best possible implementation for this n=
ew switch semantic would be most optimal when all cases are constexpr and c=
an be made jump tables at compile time. However, there should probably be a=
 level 4 warning for any non constexpr expressions in case labels to warn a=
bout possible runtime overheads.

I think that would be overkill. The compiler can find constants without hel=
p, and proper performance analysis will find any issues, whatever they are.

If any core language feature is appropriate, it=E2=80=99s to recycle the ca=
se keyword by making it context-sensitive, so the underscore in case_ can b=
e dropped.

I've written and posted such a utility before, but can't find it now. I sho=
uld clean this one up a bit and put it on GitHub.

--=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=_CE82CA92-A23D-4AE3-86AA-96A813ED9F0B
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"">How about a librar=
y solution?<div class=3D""><br class=3D""></div><div class=3D""><font face=
=3D"Courier" class=3D"">template&lt; typename operand, typename comparison =
=3D std::equal_to&lt;&gt; &gt;</font></div><div class=3D""><font face=3D"Co=
urier" class=3D"">class bound_comparison {</font></div><div class=3D""><fon=
t face=3D"Courier" class=3D"">&nbsp; &nbsp; comparison c;</font></div><div =
class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; operand o;</font=
></div><div class=3D""><font face=3D"Courier" class=3D"">public:</font></di=
v><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; bound_com=
parison( operand &amp;&amp; in_o, comparison in_c =3D {} )</font></div><div=
 class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; :=
 o( std::forward&lt;&nbsp;operand &gt;( in_o ) ), c( std::move( in_c ) ) {}=
</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"">&nbsp; &n=
bsp; template&lt; typename lhs &gt;</font></div><div class=3D""><font face=
=3D"Courier" class=3D"">&nbsp; &nbsp; bool operator () ( lhs const &amp; l =
) const</font></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp=
; &nbsp; &nbsp; &nbsp; { return c( l, o ); }</font></div><div class=3D""><f=
ont face=3D"Courier" class=3D""><br class=3D""></font></div><div class=3D""=
><font face=3D"Courier" class=3D"">&nbsp; &nbsp; bool operator () ( std::in=
itializer_list&lt; std::decay_t&lt; operand &gt; &gt; il ) const</font></di=
v><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &n=
bsp; { return std::find( il.begin(), il.end(), o ) !=3D il.end(); }</font><=
/div><div class=3D""><font face=3D"Courier" class=3D""><br class=3D""></fon=
t></div><div class=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std=
::decay_t&lt; operand &gt; const &amp; get_value() const</font></div><div c=
lass=3D""><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; { r=
eturn o; }</font></div><div class=3D""><font face=3D"Courier" class=3D"">};=
</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"">template&=
lt; typename comparison =3D std::equal_to&lt;&gt;, typename operand &gt;</f=
ont></div><div class=3D""><font face=3D"Courier" class=3D"">bound_compariso=
n&lt; operand, comparison &gt; bind_comparator( operand &amp;&amp; o, compa=
rison c =3D {} )</font></div><div class=3D""><font face=3D"Courier" class=
=3D"">&nbsp; &nbsp; { return { std::forward&lt; operand &gt;( o ), std::mov=
e( c ) }; }</font></div><div class=3D""><br class=3D""></div><div class=3D"=
"><br class=3D""></div><div class=3D""><div><blockquote type=3D"cite" class=
=3D""><div class=3D"">On 2015=E2=80=9306=E2=80=9320, at 6:49 AM, Izzy Codin=
g &lt;<a href=3D"mailto:matthew.i.greenwood@gmail.com" class=3D"">matthew.i=
..greenwood@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-new=
line"><div class=3D"">I would say that given we are now in an era of modern=
 c++, the limitations of the case labels should be explicitly comparable (e=
ither by being the correct type or to be convertible via an explicit constr=
uctor / assignment operator)<br class=3D""></div></blockquote><div><br clas=
s=3D""></div><div><font face=3D"Courier" class=3D"">auto case_ =3D bind_com=
parator( std::cin.get() );</font></div><div><font face=3D"Courier" class=3D=
"">if (&nbsp;</font><span style=3D"font-family: Courier;" class=3D"">case_<=
/span><font face=3D"Courier" class=3D"">( '</font><font face=3D"Courier" cl=
ass=3D"">-'</font><span style=3D"font-family: Courier;" class=3D"">&nbsp;) =
) {</span></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std::c=
out &lt;&lt;&nbsp;"dash\n";</font></div><div><span style=3D"font-family: Co=
urier;" class=3D"">} else if ( c( 48 ) ) {</span></div><div><span style=3D"=
font-family: Courier;" class=3D"">&nbsp; &nbsp; std::cout &lt;&lt; "nought\=
n";</span></div><div><span style=3D"font-family: Courier;" class=3D"">}</sp=
an></div><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><di=
v class=3D"">I would also suggest that the switch expression be able to acc=
ept any functional expression (e.g. Lamda function).<br class=3D""></div></=
blockquote><div><br class=3D""></div><div>Even better if no lambda is neede=
d:</div><div><br class=3D""></div><div><font face=3D"Courier" class=3D"">el=
se if ( std::isspace(&nbsp;</font><span style=3D"font-family: Courier;" cla=
ss=3D"">case_</span><font face=3D"Courier" class=3D"">.get_value() ) ) {</f=
ont></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std::cout &l=
t;&lt;&nbsp;"space out\n";</font></div><div><font face=3D"Courier" class=3D=
"">}</font></div><br class=3D""><blockquote type=3D"cite" class=3D""><div c=
lass=3D"">I would also suggest providing a comma operator to the case keywo=
rd to allow multiple options for each block and do away with the fall throu=
gh ability (which could be implemented if required using goto).<br class=3D=
""></div></blockquote><div><br class=3D""></div><div><font face=3D"Courier"=
 class=3D"">else if (&nbsp;</font><span style=3D"font-family: Courier;" cla=
ss=3D"">case_</span><font face=3D"Courier" class=3D"">({ 'X',&nbsp;'x' }) )=
 {</font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; std::co=
ut &lt;&lt; "equis\n";</font></div><div><font face=3D"Courier" class=3D"">}=
</font></div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D"">Ultimately I would imply that the best possible implementation for th=
is new switch semantic would be most optimal when all cases are constexpr a=
nd can be made jump tables at compile time. However, there should probably =
be a level 4 warning for any non constexpr expressions in case labels to wa=
rn about possible runtime overheads.<br class=3D""></div></blockquote></div=
><br class=3D""></div><div class=3D"">I think that would be overkill. The c=
ompiler can find constants without help, and proper performance analysis wi=
ll find any issues, whatever they are.</div><div class=3D""><br class=3D"">=
</div><div class=3D"">If any core language feature is appropriate, it=E2=80=
=99s to recycle the <font face=3D"Courier" class=3D"">case</font> keyword b=
y making it context-sensitive, so the underscore in <font face=3D"Courier" =
class=3D"">case_</font> can be dropped.</div><div class=3D""><br class=3D""=
></div><div class=3D"">I've written and posted such a utility before, but c=
an't find it now. I should clean this one up a bit and put it on GitHub.</d=
iv><div class=3D""><br class=3D""></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=_CE82CA92-A23D-4AE3-86AA-96A813ED9F0B--

.

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

An extended switch statement could provide the grounds for a pattern
matching engine for variants:

std::variant<int, bool, std::string, long> v;

switch(v) {
  case type<int>:
  case type<long>:
    // do number stuff
    break;
  case type<bool>:
    // do bool stuff
    break;
  default:
    assert(false);
}


On 21 June 2015 at 14:49, David Krauss <potswa@gmail.com> wrote:

> How about a library solution?
>
> template< typename operand, typename comparison =3D std::equal_to<> >
> class bound_comparison {
>     comparison c;
>     operand o;
> public:
>     bound_comparison( operand && in_o, comparison in_c =3D {} )
>         : o( std::forward< operand >( in_o ) ), c( std::move( in_c ) ) {}
>
>     template< typename lhs >
>     bool operator () ( lhs const & l ) const
>         { return c( l, o ); }
>
>     bool operator () ( std::initializer_list< std::decay_t< operand > > i=
l
> ) const
>         { return std::find( il.begin(), il.end(), o ) !=3D il.end(); }
>
>     std::decay_t< operand > const & get_value() const
>         { return o; }
> };
>
> template< typename comparison =3D std::equal_to<>, typename operand >
> bound_comparison< operand, comparison > bind_comparator( operand && o,
> comparison c =3D {} )
>     { return { std::forward< operand >( o ), std::move( c ) }; }
>
>
> On 2015=E2=80=9306=E2=80=9320, at 6:49 AM, Izzy Coding <matthew.i.greenwo=
od@gmail.com>
> wrote:
>
> I would say that given we are now in an era of modern c++, the limitation=
s
> of the case labels should be explicitly comparable (either by being the
> correct type or to be convertible via an explicit constructor / assignmen=
t
> operator)
>
>
> auto case_ =3D bind_comparator( std::cin.get() );
> if ( case_( '-' ) ) {
>     std::cout << "dash\n";
> } else if ( c( 48 ) ) {
>     std::cout << "nought\n";
> }
>
> I would also suggest that the switch expression be able to accept any
> functional expression (e.g. Lamda function).
>
>
> Even better if no lambda is needed:
>
> else if ( std::isspace( case_.get_value() ) ) {
>     std::cout << "space out\n";
> }
>
> I would also suggest providing a comma operator to the case keyword to
> allow multiple options for each block and do away with the fall through
> ability (which could be implemented if required using goto).
>
>
> else if ( case_({ 'X', 'x' }) ) {
>     std::cout << "equis\n";
> }
>
> Ultimately I would imply that the best possible implementation for this
> new switch semantic would be most optimal when all cases are constexpr an=
d
> can be made jump tables at compile time. However, there should probably b=
e
> a level 4 warning for any non constexpr expressions in case labels to war=
n
> about possible runtime overheads.
>
>
> I think that would be overkill. The compiler can find constants without
> help, and proper performance analysis will find any issues, whatever they
> are.
>
> If any core language feature is appropriate, it=E2=80=99s to recycle the =
case
> keyword by making it context-sensitive, so the underscore in case_ can be
> dropped.
>
> I've written and posted such a utility before, but can't find it now. I
> should clean this one up a bit and put it on GitHub.
>
>  --
>
> ---
> 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/.
>

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

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div>An =
extended switch statement could provide the grounds for a pattern matching =
engine for variants:<br><br></div>std::variant&lt;int, bool, std::string, l=
ong&gt; v;<br><br></div>switch(v) {<br></div>=C2=A0 case type&lt;int&gt;:<b=
r></div>=C2=A0 case type&lt;long&gt;:<br></div>=C2=A0=C2=A0=C2=A0 // do num=
ber stuff<br></div>=C2=A0=C2=A0=C2=A0 break;<br></div>=C2=A0 case type&lt;b=
ool&gt;:<br></div>=C2=A0=C2=A0=C2=A0 // do bool stuff<br></div>=C2=A0=C2=A0=
=C2=A0 break;<br></div>=C2=A0 default:<br></div>=C2=A0=C2=A0=C2=A0 assert(f=
alse);<br><div><div><div><div><div><div><div><div><div>}<br><br></div></div=
></div></div></div></div></div></div></div></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On 21 June 2015 at 14:49, David Krauss <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">pot=
swa@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 =
style=3D"word-wrap:break-word">How about a library solution?<div><br></div>=
<div><font face=3D"Courier">template&lt; typename operand, typename compari=
son =3D std::equal_to&lt;&gt; &gt;</font></div><div><font face=3D"Courier">=
class bound_comparison {</font></div><div><font face=3D"Courier">=C2=A0 =C2=
=A0 comparison c;</font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 ope=
rand o;</font></div><div><font face=3D"Courier">public:</font></div><div><f=
ont face=3D"Courier">=C2=A0 =C2=A0 bound_comparison( operand &amp;&amp; in_=
o, comparison in_c =3D {} )</font></div><div><font face=3D"Courier">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 : o( std::forward&lt;=C2=A0operand &gt;( in_o ) ), c( =
std::move( in_c ) ) {}</font></div><div><font face=3D"Courier"><br></font><=
/div><div><font face=3D"Courier">=C2=A0 =C2=A0 template&lt; typename lhs &g=
t;</font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 bool operator () (=
 lhs const &amp; l ) const</font></div><div><font face=3D"Courier">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 { return c( l, o ); }</font></div><div><font face=3D"C=
ourier"><br></font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 bool ope=
rator () ( std::initializer_list&lt; std::decay_t&lt; operand &gt; &gt; il =
) const</font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 { return std::find( il.begin(), il.end(), o ) !=3D il.end(); }</font></div=
><div><font face=3D"Courier"><br></font></div><div><font face=3D"Courier">=
=C2=A0 =C2=A0 std::decay_t&lt; operand &gt; const &amp; get_value() const</=
font></div><div><font face=3D"Courier">=C2=A0 =C2=A0 =C2=A0 =C2=A0 { return=
 o; }</font></div><div><font face=3D"Courier">};</font></div><div><font fac=
e=3D"Courier"><br></font></div><div><font face=3D"Courier">template&lt; typ=
ename comparison =3D std::equal_to&lt;&gt;, typename operand &gt;</font></d=
iv><div><font face=3D"Courier">bound_comparison&lt; operand, comparison &gt=
; bind_comparator( operand &amp;&amp; o, comparison c =3D {} )</font></div>=
<div><font face=3D"Courier">=C2=A0 =C2=A0 { return { std::forward&lt; opera=
nd &gt;( o ), std::move( c ) }; }</font></div><div><br></div><div><br></div=
><div><div><span class=3D""><blockquote type=3D"cite"><div>On 2015=E2=80=93=
06=E2=80=9320, at 6:49 AM, Izzy Coding &lt;<a href=3D"mailto:matthew.i.gree=
nwood@gmail.com" target=3D"_blank">matthew.i.greenwood@gmail.com</a>&gt; wr=
ote:</div><br><div>I would say that given we are now in an era of modern c+=
+, the limitations of the case labels should be explicitly comparable (eith=
er by being the correct type or to be convertible via an explicit construct=
or / assignment operator)<br></div></blockquote><div><br></div></span><div>=
<font face=3D"Courier">auto case_ =3D bind_comparator( std::cin.get() );</f=
ont></div><div><font face=3D"Courier">if (=C2=A0</font><span style=3D"font-=
family:Courier">case_</span><font face=3D"Courier">( &#39;</font><font face=
=3D"Courier">-&#39;</font><span style=3D"font-family:Courier">=C2=A0) ) {</=
span></div><div><font face=3D"Courier">=C2=A0 =C2=A0 std::cout &lt;&lt;=C2=
=A0&quot;dash\n&quot;;</font></div><div><span style=3D"font-family:Courier"=
>} else if ( c( 48 ) ) {</span></div><div><span style=3D"font-family:Courie=
r">=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;nought\n&quot;;</span></div><span=
 class=3D""><div><span style=3D"font-family:Courier">}</span></div><div><br=
></div><blockquote type=3D"cite"><div>I would also suggest that the switch =
expression be able to accept any functional expression (e.g. Lamda function=
).<br></div></blockquote><div><br></div></span><div>Even better if no lambd=
a is needed:</div><div><br></div><div><font face=3D"Courier">else if ( std:=
:isspace(=C2=A0</font><span style=3D"font-family:Courier">case_</span><font=
 face=3D"Courier">.get_value() ) ) {</font></div><div><font face=3D"Courier=
">=C2=A0 =C2=A0 std::cout &lt;&lt;=C2=A0&quot;space out\n&quot;;</font></di=
v><span class=3D""><div><font face=3D"Courier">}</font></div><br><blockquot=
e type=3D"cite"><div>I would also suggest providing a comma operator to the=
 case keyword to allow multiple options for each block and do away with the=
 fall through ability (which could be implemented if required using goto).<=
br></div></blockquote><div><br></div></span><div><font face=3D"Courier">els=
e if (=C2=A0</font><span style=3D"font-family:Courier">case_</span><font fa=
ce=3D"Courier">({ &#39;X&#39;,=C2=A0&#39;x&#39; }) ) {</font></div><div><fo=
nt face=3D"Courier">=C2=A0 =C2=A0 std::cout &lt;&lt; &quot;equis\n&quot;;</=
font></div><span class=3D""><div><font face=3D"Courier">}</font></div><br><=
blockquote type=3D"cite"><div>Ultimately I would imply that the best possib=
le implementation for this new switch semantic would be most optimal when a=
ll cases are constexpr and can be made jump tables at compile time. However=
, there should probably be a level 4 warning for any non constexpr expressi=
ons in case labels to warn about possible runtime overheads.<br></div></blo=
ckquote></span></div><br></div><div>I think that would be overkill. The com=
piler can find constants without help, and proper performance analysis will=
 find any issues, whatever they are.</div><div><br></div><div>If any core l=
anguage feature is appropriate, it=E2=80=99s to recycle the <font face=3D"C=
ourier">case</font> keyword by making it context-sensitive, so the undersco=
re in <font face=3D"Courier">case_</font> can be dropped.</div><div><br></d=
iv><div>I&#39;ve written and posted such a utility before, but can&#39;t fi=
nd it now. I should clean this one up a bit and put it on GitHub.</div><div=
><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7b3a802c9d4585051917f560--

.

--Apple-Mail=_8B6FAB1B-F053-44D9-AD58-42A7981663D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9322, at 5:32 PM, Sam Kellett <samkellett@gmail.=
com> wrote:
>=20
> An extended switch statement could provide the grounds for a pattern matc=
hing engine for variants:

This example isn't really a =E2=80=9Cpattern-matching engine.=E2=80=9D On t=
he other hand, switch-based coroutines are the basis of the Mach7 <https://=
github.com/solodon4/Mach7> pattern-matching library.

> std::variant<int, bool, std::string, long> v;
>=20
> switch(v) {
>   case type<int>:

This seems to presuppose a tag called type<int> (maybe a variable template =
std::type<int>?) which is comparable with std::variant.

It would be better to support comparison operations besides operator=3D=3D,=
 say []( auto const & v, std::type_info const & t ) { return v.get_type() =
=3D=3D t; }. It's easier to put that kind of hook into a library than into =
a built-in switch statement.

And, I've now published such a library, based on my previous message:

 https://github.com/potswa/safe_switch <https://github.com/potswa/safe_swit=
ch>

It supports both transparent style like else if( case_({ 5, 6 }) ), and mac=
ro-sugared CASE({ 5, 6 }).

Share and enjoy!

--=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=_8B6FAB1B-F053-44D9-AD58-42A7981663D1
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=9306=
=E2=80=9322, at 5:32 PM, Sam Kellett &lt;<a href=3D"mailto:samkellett@gmail=
..com" class=3D"">samkellett@gmail.com</a>&gt; wrote:</div><br class=3D"Appl=
e-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><div cla=
ss=3D""><div class=3D""><div class=3D""><div class=3D""><div class=3D""><di=
v class=3D""><div class=3D""><div class=3D""><div class=3D""><div class=3D"=
"><div class=3D"">An extended switch statement could provide the grounds fo=
r a pattern matching engine for variants:<br class=3D""></div></div></div><=
/div></div></div></div></div></div></div></div></div></div></blockquote><di=
v><br class=3D""></div><div>This example isn't really a =E2=80=9Cpattern-ma=
tching engine.=E2=80=9D On the other hand, <font face=3D"Courier" class=3D"=
">switch</font>-based coroutines are the basis of the&nbsp;<a href=3D"https=
://github.com/solodon4/Mach7" class=3D"">Mach7</a>&nbsp;pattern-matching li=
brary.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D""><div dir=3D"ltr" class=3D""><div class=3D""><div class=3D""><div clas=
s=3D""><div class=3D""><div class=3D""><div class=3D""><div class=3D""><div=
 class=3D""><div class=3D""><div class=3D"">std::variant&lt;int, bool, std:=
:string, long&gt; v;<br class=3D""><br class=3D""></div>switch(v) {<br clas=
s=3D""></div>&nbsp; case type&lt;int&gt;:<br class=3D""></div></div></div><=
/div></div></div></div></div></div></div></blockquote><div><br class=3D""><=
/div><div>This seems to presuppose a tag called <font face=3D"Courier" clas=
s=3D"">type&lt;int&gt;</font> (maybe a variable template&nbsp;<font face=3D=
"Courier" class=3D"">std::type&lt;int&gt;</font>?) which is comparable with=
 <font face=3D"Courier" class=3D"">std::variant</font>.</div><div><br class=
=3D""></div><div>It would be better to support comparison operations beside=
s <font face=3D"Courier" class=3D"">operator=3D=3D</font>, say&nbsp;<font f=
ace=3D"Courier" class=3D"">[]( auto const &amp; v, std::type_info const &am=
p; t ) { return v.get_type() =3D=3D t; }</font>. It's easier to put that ki=
nd of hook into a library than into a built-in <font face=3D"Courier" class=
=3D"">switch</font> statement.</div><div><br class=3D""></div><div>And, I'v=
e now published such a library, based on my previous message:</div><div><br=
 class=3D""></div><div><span class=3D"Apple-tab-span" style=3D"white-space:=
pre"> </span><a href=3D"https://github.com/potswa/safe_switch" class=3D"">h=
ttps://github.com/potswa/safe_switch</a></div><div><br class=3D""></div><di=
v>It supports both transparent style like <font face=3D"Courier" class=3D""=
>else if( case_({ 5, 6 }) )</font>, and macro-sugared&nbsp;<font face=3D"Co=
urier" class=3D"">CASE({ 5, 6 })</font>.</div><div><br class=3D""></div><di=
v>Share and enjoy!</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=_8B6FAB1B-F053-44D9-AD58-42A7981663D1--

.

------=_Part_4319_711123014.1435056950156
Content-Type: multipart/alternative;
 boundary="----=_Part_4320_1098000743.1435056950156"

------=_Part_4320_1098000743.1435056950156
Content-Type: text/plain; charset=UTF-8



On Friday, June 19, 2015 at 11:49:52 PM UTC+1, Izzy Coding wrote:
>
> I would also suggest providing a comma operator to the case keyword to
> allow multiple options for each block and do away with the fall through
> ability (which could be implemented if required using goto).
>
>
Although I sympathize with your suggestion it could break code since we can
already define a constexpr comma operator for an enum and use it in labels:

#include <iostream>

enum class color { red, green, blue };

constexpr color operator ,(color c1, color c2) {
    if (c1 == color::red && c2 == color::green)
        return color::blue;
    return color::red;
}

void f(color c) {
    switch (c) {
        case (color::red, color::green):
            std::cout << "red or green\n";
            break;
        default:
            std::cout << "blue\n";
    }
}

int main() {
    f(color::red);   // outputs "blue"
    f(color::green); // outputs "blue"
    f(color::blue);  // outputs "red or green"
}

Regards,
Cassio.

--

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

<div dir=3D"ltr"><br><br>On Friday, June 19, 2015 at 11:49:52 PM UTC+1, Izz=
y Coding wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would also su=
ggest providing a comma operator to the case keyword to allow multiple opti=
ons for each block and do away with the fall through ability (which could b=
e implemented if required using goto).
<br>
<br></blockquote><div><br>Although I sympathize with your suggestion it cou=
ld break code since we can<br>already define a constexpr comma operator for=
 an enum and use it in labels:<br><br>#include &lt;iostream&gt;<br><br>enum=
 class color { red, green, blue };<br><br>constexpr color operator ,(color =
c1, color c2) {<br>&nbsp;&nbsp;&nbsp; if (c1 =3D=3D color::red &amp;&amp; c=
2 =3D=3D color::green)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return=
 color::blue;<br>&nbsp;&nbsp;&nbsp; return color::red;<br>}<br><br>void f(c=
olor c) {<br>&nbsp;&nbsp;&nbsp; switch (c) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; case (color::red, color::green):<br>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; "red or gree=
n\n";<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 break;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; default:<br>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::cout &lt;&lt=
; "blue\n";<br>&nbsp;&nbsp;&nbsp; }<br>}<br><br>int main() {<br>&nbsp;&nbsp=
;&nbsp; f(color::red);&nbsp;&nbsp; // outputs "blue"<br>&nbsp;&nbsp;&nbsp; =
f(color::green); // outputs "blue"<br>&nbsp;&nbsp;&nbsp; f(color::blue);&nb=
sp; // outputs "red or green"<br>}<br><br>Regards,<br>Cassio.<br></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_4320_1098000743.1435056950156--
------=_Part_4319_711123014.1435056950156--

.

On Tuesday 23 June 2015 16:27:41 David Krauss wrote:
> > switch(v) {
> >
> >   case type<int>:
> This seems to presuppose a tag called type<int> (maybe a variable templat=
e
> std::type<int>?) which is comparable with std::variant.

SImilar to QVariant:

 switch (v.type()) {
 case qMetaTypeId<int>():
 case qMetaTypeId<QString>():
  ...
 }

Unfortunately, qMetaTypeId<T>() is not a constexpr for dynamic types (anyth=
ing=20
bout the 60 or so that are pre-assigned a number) so you can't put those in=
 a=20
switch. So the question is what could we do so that it became switchable.

The only thing that comes to mind is to return the address of the=20
typeid(std::remove_cv<T>::type), but typeid is not constexpr either.

Any other ideas?

Here's my attempt so far:

constexpr std::type_info *nulltypeinfo() { return nullptr; }=20
template <typename T> constexpr long type()=20
{ return &typeid(T) - nulltypeinfo(); }=20

void f1(), f2(), f3();=20
void f(long id)
{=20
 switch(id) {=20
 case type<int>(): f1(); break;=20
 case type<long>(): f2(); break;=20
 default: f3();=20
 }=20
}

GCC has the best error message:
  in constexpr expansion of =E2=80=98type<int>()=E2=80=99
error: =E2=80=98(((long int)(& _ZTIi)) (ceiling /) 16l)=E2=80=99 is not a c=
onstant expression

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

.

22.06.2015 12:32, Sam Kellett:
> An extended switch statement could provide the grounds for a pattern
> matching engine for variants:
>
> std::variant<int, bool, std::string, long> v;
>
> switch(v) {
>    case type<int>:
>    case type<long>:
>      // do number stuff
>      break;
>    case type<bool>:
>      // do bool stuff
>      break;
>    default:
>      assert(false);
> }

1. Such syntax would require to do double check of variant tag - one
within switch(v), and another within case where value is extracted (or
perform dangerous unchecked_get<T>).

2. Ad-hoc pattern matching for variants is already possible via
overload-sets + lambdas.
Here is an example of syntax:

for(auto x : xs)
     ys.push_back
     (
         MATCH(x)
             CASE(x IS widget) { use_as_widget(x); return 1; }
             CASE(x IS gadget) { use_as_gadget(x); return 0.1;}
     );

And note, MATCH is expression, not statement.
Live Demo: http://coliru.stacked-crooked.com/a/be015fc33ecc5ee7

--
Evgeny Panasyuk

--

---
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=_89E03B43-1FA4-43D8-A2A7-DD8D75C91527
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9324, at 12:02 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> SImilar to QVariant:
>=20
>  switch (v.type()) {
>  case qMetaTypeId<int>():
>  case qMetaTypeId<QString>():
>   ...
>  }
>=20
> Unfortunately, qMetaTypeId<T>() is not a constexpr for dynamic types (any=
thing=20
> bout the 60 or so that are pre-assigned a number) so you can't put those =
in a=20
> switch. So the question is what could we do so that it became switchable.

switch doesn=E2=80=99t only require constant expressions, it requires integ=
er or enumeration type and a unique value for each case. C++ won=E2=80=99t =
map compile-time pointers to integers because there is no global address sp=
ace at compile time.

If type_info::hash_code were constexpr, then you would have enough to switc=
h on, provided no hash collisions. But the advantage of switch over if-else=
 is lost for sparse mappings. It=E2=80=99s fundamentally impossible to get =
a compile-time map from all types across TUs to sequential integers. You ca=
n only have two of the three: non-enumerated types, external linkage, and c=
ompile-time integers.

Hash collisions would randomly break builds, which sounds like a non-starte=
r for Qt.

So, you might as well use if-else. See my library for switch-like syntactic=
 sugar. If you want to adopt it and call the macro QSwitch, be my guest :) =
..

--=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=_89E03B43-1FA4-43D8-A2A7-DD8D75C91527
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=9306=
=E2=80=9324, at 12:02 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">SImilar to QVariant:<br class=3D"=
"><br class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>switch (v.type()) {<br class=3D""><span class=3D"Apple-tab-span" sty=
le=3D"white-space:pre"> </span>case qMetaTypeId&lt;int&gt;():<br class=3D""=
><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>case qMet=
aTypeId&lt;QString&gt;():<br class=3D""><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre"> </span><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span>...<br class=3D""><span class=3D"Apple-tab-span" style=
=3D"white-space:pre"> </span>}<br class=3D""><br class=3D"">Unfortunately, =
qMetaTypeId&lt;T&gt;() is not a constexpr for dynamic types (anything <br c=
lass=3D"">bout the 60 or so that are pre-assigned a number) so you can't pu=
t those in a <br class=3D"">switch. So the question is what could we do so =
that it became switchable.<br class=3D""></div></blockquote><div><br class=
=3D""></div><div><font face=3D"Courier" class=3D"">switch</font> doesn=E2=
=80=99t only require constant expressions, it requires integer or enumerati=
on type and a unique value for each case. C++ won=E2=80=99t map compile-tim=
e pointers to integers because there is no global address space at compile =
time.</div><div><br class=3D""></div><div>If <font face=3D"Courier" class=
=3D"">type_info::hash_code</font>&nbsp;were constexpr, then you would have =
enough to switch on, provided no hash collisions. But the advantage of <fon=
t face=3D"Courier" class=3D"">switch</font> over <font face=3D"Courier" cla=
ss=3D"">if</font>-<font face=3D"Courier" class=3D"">else</font> is lost for=
 sparse mappings. It=E2=80=99s fundamentally impossible to get a compile-ti=
me map from all types across TUs to sequential integers. You can only have =
two of the three: non-enumerated types, external linkage, and compile-time =
integers.</div><div><br class=3D""></div><div>Hash collisions would randoml=
y break builds, which sounds like a non-starter for Qt.</div><div><br class=
=3D""></div><div>So, you might as well use <font face=3D"Courier" class=3D"=
">if</font>-<font face=3D"Courier" class=3D"">else</font>. See my library f=
or <font face=3D"Courier" class=3D"">switch</font>-like syntactic sugar. If=
 you want to adopt it and call the macro&nbsp;<font face=3D"Courier" class=
=3D"">QSwitch</font>, be my guest :) .</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=_89E03B43-1FA4-43D8-A2A7-DD8D75C91527--

.

------=_Part_5182_1252312390.1435105558478
Content-Type: multipart/alternative;
 boundary="----=_Part_5183_127114483.1435105558478"

------=_Part_5183_127114483.1435105558478
Content-Type: text/plain; charset=UTF-8

On Tuesday, June 23, 2015 at 6:02:40 PM UTC+2, Thiago Macieira wrote:
>
> The only thing that comes to mind is to return the address of the
> typeid(std::remove_cv<T>::type), but typeid is not constexpr either.
>

Besides the other problems with this mentioned by David Krauss: Be careful,
the standard does not guarantee that &typeid(T) == &typeid(T).

--

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

<div dir=3D"ltr">On Tuesday, June 23, 2015 at 6:02:40 PM UTC+2, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The only thing that=
 comes to mind is to return the address of the=20
<br>typeid(std::remove_cv&lt;T&gt;::<wbr>type), but typeid is not constexpr=
 either.
<br></blockquote><div><br></div><div>Besides the other problems with this m=
entioned by David Krauss: Be careful, the standard does not guarantee that =
<font face=3D"courier new, monospace">&amp;typeid(T) =3D=3D &amp;typeid(T)<=
/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_5183_127114483.1435105558478--
------=_Part_5182_1252312390.1435105558478--

.

On Tuesday 23 June 2015 17:25:58 Max Truxa wrote:
> On Tuesday, June 23, 2015 at 6:02:40 PM UTC+2, Thiago Macieira wrote:
> > The only thing that comes to mind is to return the address of the
> > typeid(std::remove_cv<T>::type), but typeid is not constexpr either.
>
> Besides the other problems with this mentioned by David Krauss: Be careful,
> the standard does not guarantee that &typeid(T) == &typeid(T).

Wouldn't that be an ODR violation?

I understand how it happens in DLLs and hidden visibility ELF libraries, but
I've always thought it was caused by explicit ODR violation.
--
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=_5D86F6F8-FA0F-41A2-A5D1-8F4B52536369
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9324, at 10:20 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> On Tuesday 23 June 2015 17:25:58 Max Truxa wrote:
>> the standard does not guarantee that &typeid(T) =3D=3D &typeid(T).
>=20
> Wouldn't that be an ODR violation?

type_info objects aren=E2=80=99t declared, so they aren=E2=80=99t subject t=
o the ODR.

You can manually declare something (e.g. a function template or a static me=
mber of a class template) if you want to compare addresses.

> I understand how it happens in DLLs and hidden visibility ELF libraries, =
but=20
> I've always thought it was caused by explicit ODR violation.

The C++ standard doesn=E2=80=99t describe hidden visibility. Doing so, thou=
gh, should only require a notion of an unnamed namespace shared between som=
e TUs but not others. It=E2=80=99s basically linkage which is external up t=
o a point, then internal.

It would be nice to see a proposal. It=E2=80=99s a somewhat obscure feature=
, but it seems to be widely implemented and important to DLL ABI specificat=
ion in practice. It should be conforming.

--=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=_5D86F6F8-FA0F-41A2-A5D1-8F4B52536369
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=9306=
=E2=80=9324, at 10:20 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">On Tuesday 23 June 2015 17:25:58 =
Max Truxa wrote:<br class=3D""><blockquote type=3D"cite" class=3D"">the sta=
ndard does not guarantee that &amp;typeid(T) =3D=3D &amp;typeid(T).<br clas=
s=3D""></blockquote><br class=3D"">Wouldn't that be an ODR violation?<br cl=
ass=3D""></div></blockquote><div><br class=3D""></div><div><font face=3D"Co=
urier" class=3D"">type_info</font> objects aren=E2=80=99t declared, so they=
 aren=E2=80=99t subject to the ODR.</div><div><br class=3D""></div><div>You=
 can manually declare something (e.g. a function template or a static membe=
r of a class template) if you want to compare addresses.</div><br class=3D"=
"><blockquote type=3D"cite" class=3D""><div class=3D"">I understand how it =
happens in DLLs and hidden visibility ELF libraries, but <br class=3D"">I'v=
e always thought it was caused by explicit ODR violation.<br class=3D""></d=
iv></blockquote><br class=3D""></div><div>The C++ standard doesn=E2=80=99t =
describe hidden visibility. Doing so, though, should only require a notion =
of an unnamed namespace shared between some TUs but not others. It=E2=80=99=
s basically linkage which is external up to a point, then internal.</div><d=
iv><br class=3D""></div><div>It would be nice to see a proposal. It=E2=80=
=99s a somewhat obscure feature, but it seems to be widely implemented and =
important to DLL ABI specification in practice. It should be conforming.</d=
iv></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=_5D86F6F8-FA0F-41A2-A5D1-8F4B52536369--

.

On Wednesday 24 June 2015 08:15:39 David Krauss wrote:
> > On 2015=E2=80=9306=E2=80=9324, at 12:02 AM, Thiago Macieira <thiago@mac=
ieira.org> wrote:
> >=20
> > SImilar to QVariant:
> >  switch (v.type()) {
> >  case qMetaTypeId<int>():
> > =09
> >  case qMetaTypeId<QString>():
> >   ...
> > =09
> >  }
> >=20
> > Unfortunately, qMetaTypeId<T>() is not a constexpr for dynamic types
> > (anything bout the 60 or so that are pre-assigned a number) so you can'=
t
> > put those in a switch. So the question is what could we do so that it
> > became switchable.
>
> switch doesn=E2=80=99t only require constant expressions, it requires int=
eger or
> enumeration type and a unique value for each case. C++ won=E2=80=99t map
> compile-time pointers to integers because there is no global address spac=
e
> at compile time.

I'm not sure I understood you. The standard is clear that case labels must=
=20
carry a constant expression (6.4.2 [stmt.switch] p2) and compilers agree wi=
th=20
that.

Clang: error: case value is not a constant expression
GCC: error: call to non-constexpr function =E2=80=98long int type() [with T=
 =3D int]=E2=80=99
ICC: error: function call must have a constant value in a constant expressi=
on

Were you talking about the value being switched? I didn't mean that, I real=
ly=20
meant runtime switching of the value contained in the variant.

> If type_info::hash_code were constexpr, then you would have enough to swi=
tch
> on, provided no hash collisions. But the advantage of switch over if-else
> is lost for sparse mappings. It=E2=80=99s fundamentally impossible to get=
 a
> compile-time map from all types across TUs to sequential integers. You ca=
n
> only have two of the three: non-enumerated types, external linkage, and
> compile-time integers.

Sequential isn't required, as long as it's unique and compile-time.

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

.

On Wednesday 24 June 2015 10:30:16 David Krauss wrote:
> You can manually declare something (e.g. a function template or a static
> member of a class template) if you want to compare addresses.

The program below produces a segmentation fault in ICC, a misleading=20
compilation error message from GCC and a non-useful one from Clang.

GCC: error: conversion from pointer type =E2=80=98const char*=E2=80=99 to a=
rithmetic type=20
=E2=80=98long int=E2=80=99 in a constant-expression

Clang: error: case value is not a constant expression

The question is: is the type() function below really constexpr? I'm guessin=
g=20
that the pointer subtraction is both undefined behaviour (not in the same=
=20
array) and prohibited in constexpr anyway.

template <typename T> struct TI
{ static const char id; };
template <typename T> const char TI<T>::id =3D 0;

template <typename T> constexpr long type()
{ return &TI<T>::id - (char *)0; }

void f1(), f2(), f3();
void f(long i)
{
    switch (i)
    {
    case type<int>():
        f1();
        break;
    case type<long>():
        f2();
        break;
    default:
        f3();
    }
}

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

.

--Apple-Mail=_EF1DEE82-BB49-4863-A53F-6FD3433FBCC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9324, at 11:36 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> I'm not sure I understood you. The standard is clear that case labels mus=
t=20
> carry a constant expression (6.4.2 [stmt.switch] p2) and compilers agree =
with=20
> that.

These ingredients are necessary and sufficient for an expression to make a =
case label:

1. integer or enumeration type
2. compile-time value
3. distinct value from the other labels

One more ingredient is necessary for the compiler to translate the switch d=
ifferently from an if-else chain:

4. dense clustering of values: the number of cases should be not much less =
than the difference between greatest and least case value.

You can use switch without #4, but why go to the trouble? It sounds to me l=
ike you=E2=80=99re jumping through hoops to allow users to maintain a progr=
amming practice which is aesthetic preference at best, and so error-prone t=
hat folks keep proposing to neuter it.


> On 2015=E2=80=9306=E2=80=9324, at 11:54 AM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> The program below produces a segmentation fault in ICC, a misleading=20
> compilation error message from GCC and a non-useful one from Clang.
>=20
> GCC: error: conversion from pointer type =E2=80=98const char*=E2=80=99 to=
 arithmetic type=20
> =E2=80=98long int=E2=80=99 in a constant-expression

The subtraction is an attempt to convert type char const* to type long int,=
 so GCC has intuited the intent.

> The question is: is the type() function below really constexpr? I'm guess=
ing=20
> that the pointer subtraction is both undefined behaviour (not in the same=
=20
> array) and prohibited in constexpr anyway.

You=E2=80=99ve answered your question in terms of the standard. As for a ph=
ilosophical reason, there is no address space at compile time.

However, this question appears unrelated to the quoted statement above it: =
=E2=80=9CYou can manually declare something (e.g. a function template or a =
static member of a class template) if you want to compare addresses.=E2=80=
=9D I wasn=E2=80=99t talking about switch statements, only expressions like=
 & my_typeid< T > =3D=3D & my_typeid< T >.

My advice is to forget about switch, and if users are really clamoring for =
similar syntax, synthesize <https://github.com/potswa/safe_switch> it.

--=20

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

--Apple-Mail=_EF1DEE82-BB49-4863-A53F-6FD3433FBCC2
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=9306=
=E2=80=9324, at 11:36 AM, Thiago Macieira &lt;<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D""><span style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
 widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: no=
ne; display: inline !important;" class=3D"">I'm not sure I understood you. =
The standard is clear that case labels must<span class=3D"Apple-converted-s=
pace">&nbsp;</span></span><br style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"=
font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px; float: none; display: inline !important;" class=3D"">carry a const=
ant expression (6.4.2 [stmt.switch] p2) and compilers agree with<span class=
=3D"Apple-converted-space">&nbsp;</span></span><br style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=
=3D""><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;" cla=
ss=3D"">that.</span><br style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote><d=
iv><br class=3D""></div><div>These ingredients are necessary and sufficient=
 for an expression to make a case label:</div><div><br class=3D""></div><di=
v>1. integer or enumeration type</div><div>2. compile-time value</div><div>=
3. distinct value from the other labels</div><div><br class=3D""></div><div=
>One more ingredient is necessary for the compiler to translate the switch =
differently from an if-else chain:</div><div><br class=3D""></div><div>4. d=
ense clustering of values: the number of cases should be not much less than=
 the difference between greatest and least case value.</div><div><br class=
=3D""></div><div>You <i class=3D"">can</i>&nbsp;use <font face=3D"Courier" =
class=3D"">switch</font> without #4, but why go to the trouble? It sounds t=
o me like you=E2=80=99re jumping through hoops to allow users to maintain a=
 programming practice which is aesthetic preference at best, and so error-p=
rone that folks keep proposing to neuter it.</div><div><br class=3D""></div=
><div><br class=3D""></div><div><blockquote type=3D"cite" class=3D""><div c=
lass=3D"">On 2015=E2=80=9306=E2=80=9324, at 11:54 AM, Thiago Macieira &lt;<=
a href=3D"mailto:thiago@macieira.org" class=3D"">thiago@macieira.org</a>&gt=
; wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span=
 class=3D"" style=3D"float: none; display: inline !important;">The program =
below produces a segmentation fault in ICC, a misleading&nbsp;</span><br cl=
ass=3D""><span class=3D"" style=3D"float: none; display: inline !important;=
">compilation error message from GCC and a non-useful one from Clang.</span=
><br class=3D""><br class=3D""><span class=3D"" style=3D"float: none; displ=
ay: inline !important;">GCC: error: conversion from pointer type =E2=80=98c=
onst char*=E2=80=99 to arithmetic type&nbsp;</span><br class=3D""><span cla=
ss=3D"" style=3D"float: none; display: inline !important;">=E2=80=98long in=
t=E2=80=99 in a constant-expression</span><br class=3D""></div></blockquote=
><div><br class=3D""></div><div>The subtraction <i class=3D"">is</i> an att=
empt to convert type <font face=3D"Courier" class=3D"">char const*</font> t=
o type <font face=3D"Courier" class=3D"">long int</font>, so GCC has intuit=
ed the intent.</div></div><div><br class=3D""></div><div><blockquote type=
=3D"cite" class=3D""><div class=3D"">The question is: is the type() functio=
n below really constexpr? I'm guessing&nbsp;</div><div class=3D""><span cla=
ss=3D"" style=3D"float: none; display: inline !important;">that the pointer=
 subtraction is both undefined behaviour (not in the same&nbsp;</span><br c=
lass=3D""><span class=3D"" style=3D"float: none; display: inline !important=
;">array) and prohibited in constexpr anyway.</span><br class=3D""></div></=
blockquote><div class=3D""><div class=3D""><span class=3D"" style=3D"float:=
 none; display: inline !important;"><br class=3D""></span></div></div><div =
class=3D""><span class=3D"" style=3D"float: none; display: inline !importan=
t;">You=E2=80=99ve answered your question in terms of the standard. As for =
a philosophical reason, there is no address space at compile time.</span></=
div><div class=3D""><span class=3D"" style=3D"float: none; display: inline =
!important;"><br class=3D""></span></div><div class=3D"">However, this ques=
tion appears unrelated to the quoted statement above it: =E2=80=9CYou can m=
anually declare something (e.g. a function template or a static member of a=
 class template) if you want to compare addresses.=E2=80=9D I wasn=E2=80=99=
t talking about switch statements, only expressions like <font face=3D"Cour=
ier" class=3D"">&amp; my_typeid&lt; T &gt; =3D=3D &amp; my_typeid&lt; T &gt=
;</font>.</div><div class=3D""><br class=3D""></div><div class=3D"">My advi=
ce is to forget about <font face=3D"Courier" class=3D"">switch</font>, and =
if users are really clamoring for similar syntax,&nbsp;<a href=3D"https://g=
ithub.com/potswa/safe_switch" class=3D"">synthesize</a>&nbsp;it.</div></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=_EF1DEE82-BB49-4863-A53F-6FD3433FBCC2--

.

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

On 23 June 2015 at 23:33, David Krauss <potswa@mac.com> wrote:

> One more ingredient is necessary for the compiler to translate the switch
> differently from an if-else chain:
>
> 4. dense clustering of values: the number of cases should be not much less
> than the difference between greatest and least case value.
>

Huh?  Just looking at the second result from Googling "switch statement
tree", one finds <
http://www.codeproject.com/Articles/100473/Something-You-May-Not-Know-About-the-Switch-Statem
>.


> You *can* use switch without #4, but why go to the trouble?
>

Because the compiler is far better at optimization than your limited vision
of it?
--
 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/.

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

<div dir=3D"ltr">On 23 June 2015 at 23:33, David Krauss <span dir=3D"ltr">&=
lt;<a href=3D"mailto:potswa@mac.com" target=3D"_blank">potswa@mac.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div style=3D"word-wrap:break-word">One more ingredient is =
necessary for the compiler to translate the switch differently from an if-e=
lse chain:<br><div><div><br></div><div>4. dense clustering of values: the n=
umber of cases should be not much less than the difference between greatest=
 and least case value.</div></div></div></blockquote><div><br></div><div>Hu=
h?=C2=A0 Just looking at the second result from Googling &quot;switch state=
ment tree&quot;, one finds &lt;<a href=3D"http://www.codeproject.com/Articl=
es/100473/Something-You-May-Not-Know-About-the-Switch-Statem">http://www.co=
deproject.com/Articles/100473/Something-You-May-Not-Know-About-the-Switch-S=
tatem</a>&gt;.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wr=
ap:break-word"><div>You <i>can</i>=C2=A0use <font face=3D"Courier">switch</=
font> without #4, but why go to the trouble?</div></div></blockquote><div><=
br></div><div>Because the compiler is far better at optimization than your =
limited vision of it?</div><div>--=C2=A0<br></div></div><div class=3D"gmail=
_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"m=
ailto: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 />

--001a11c37f7eca0dc505193c5a7e--

.

--Apple-Mail=_14CEEA2D-1FDD-4B6B-8C6A-772AE4998F69
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9306=E2=80=9324, at 12:57 PM, Nevin Liber <nevin@eviloverlo=
rd.com> wrote:
>=20
> Huh?  Just looking at the second result from Googling "switch statement t=
ree", one finds <http://www.codeproject.com/Articles/100473/Something-You-M=
ay-Not-Know-About-the-Switch-Statem <http://www.codeproject.com/Articles/10=
0473/Something-You-May-Not-Know-About-the-Switch-Statem>>.

There=E2=80=99s nothing the compiler can do to reverse a mapping with rando=
m distribution. Even for a consistent pattern like all cases being multiple=
s of 50, it will likely give up on table generation. Thank you for illustra=
ting my point.

> You can use switch without #4, but why go to the trouble?
>=20
> Because the compiler is far better at optimization than your limited visi=
on of it?

The compiler should also be able to detect when an if-else ladder is equiva=
lent to a switch. Even without that, it should be able to reorder if-else c=
ases with pure conditions. The article doesn=E2=80=99t mention PGO, which i=
s essential in my experience. To say that if-else and switch are fundamenta=
lly different belies =E2=80=9Climited vision.=E2=80=9D

--=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=_14CEEA2D-1FDD-4B6B-8C6A-772AE4998F69
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=9306=
=E2=80=9324, at 12:57 PM, Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverl=
ord.com" class=3D"">nevin@eviloverlord.com</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"">Huh?&nbs=
p; Just looking at the second result from Googling "switch statement tree",=
 one finds &lt;<a href=3D"http://www.codeproject.com/Articles/100473/Someth=
ing-You-May-Not-Know-About-the-Switch-Statem" class=3D"">http://www.codepro=
ject.com/Articles/100473/Something-You-May-Not-Know-About-the-Switch-Statem=
</a>&gt;.</div></div></div></div></div></blockquote><div><br class=3D""></d=
iv><div>There=E2=80=99s nothing the compiler can do to reverse a mapping wi=
th random distribution. Even for a consistent pattern like all cases being =
multiples of 50, it will likely give up on table generation. Thank you for =
illustrating my point.</div><div><br class=3D""></div><blockquote type=3D"c=
ite" class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"=
 class=3D""><div class=3D"">You <i class=3D"">can</i>&nbsp;use <font face=
=3D"Courier" class=3D"">switch</font> without #4, but why go to the trouble=
?</div></div></blockquote><div class=3D""><br class=3D""></div><div class=
=3D"">Because the compiler is far better at optimization than your limited =
vision of it?</div></div></div></div></blockquote><br class=3D""></div><div=
>The compiler should also be able to detect when an if-else ladder is equiv=
alent to a switch. Even without that, it should be able to reorder if-else =
cases with pure conditions. The article doesn=E2=80=99t mention PGO, which =
is essential in my experience. To say that if-else and switch are fundament=
ally different belies =E2=80=9Climited vision.=E2=80=9D</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=_14CEEA2D-1FDD-4B6B-8C6A-772AE4998F69--

.

On Wednesday 24 June 2015 12:33:59 David Krauss wrote:
> My advice is to forget about switch, and if users are really clamoring for
> similar syntax, synthesize <https://github.com/potswa/safe_switch> it.

My users aren't asking for it. I was just reacting to an earlier email in the
list that was.

For an if-else chain, the problem is solved already.
--
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/.

.