------=_Part_230_32438411.1374157566167
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Perhaps, it has been discussed before, but I have had a minor issue with
the standard for many years now. I have wished to have a feature for
supporting ranges inside switch statements for the cases. As it seems, gcc
already has an extension [1] for that.

What do you think?

Cheers,
Laszlo

[1] http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Case-Ranges.html

--

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



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

Hi,<div><br></div><div>Perhaps, it has been discussed before, but I have ha=
d a minor issue with the standard for many years now. I have wished to have=
 a feature for supporting ranges inside switch statements for the cases. As=
 it seems, gcc already has an extension [1] for that.</div><div><br></div><=
div>What do you think?</div><div><br></div><div>Cheers,</div><div>Laszlo</d=
iv><div><br></div><div>[1]&nbsp;<a href=3D"http://gcc.gnu.org/onlinedocs/gc=
c-4.1.2/gcc/Case-Ranges.html">http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/C=
ase-Ranges.html</a></div>

<p></p>

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

------=_Part_230_32438411.1374157566167--

.

------=_Part_11_14624341.1374177800369
Content-Type: text/plain; charset=ISO-8859-1

Hey,

I don't really like the '...' syntax they use, since (as they already
mention on that page) in 1...2, the first token will be '1.', not  '1', and
things get ugly.
However, this isn't much different than the problems with >> and
<::> that have been fixed in C++11. Another rule could be added for
"...", such that 1...2 parses correctly.

A slightly weak argument against allowing the range case syntax is that
almost certainly it'll be used as "case 'a'...'z'", which would be bad,
since that range is not necessarily "abcdefghijklmnopqrstuvwxyz".

More importantly, I don't think there are much use cases for range case
labels, since for characters std::is{alpha,digit,....} usually already
provides superior functionality, and for other integral types, an
if-statement with comparison operators is likely more appropriate.

Did you run into a situation where a range case label would make your code
better?

-Maurice-



Op donderdag 18 juli 2013 16:26:06 UTC+2 schreef Laszlo Papp het volgende:
>
> Hi,
>
> Perhaps, it has been discussed before, but I have had a minor issue with
> the standard for many years now. I have wished to have a feature for
> supporting ranges inside switch statements for the cases. As it seems, gcc
> already has an extension [1] for that.
>
> What do you think?
>
> Cheers,
> Laszlo
>
> [1] http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Case-Ranges.html
>

--

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



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

Hey,<br><br>I don't really like the '...' syntax they use, since (as they a=
lready mention on that page) in 1...2, the first token will be '1.', not&nb=
sp; '1', and things get ugly.<br>However, this isn't much different than th=
e problems with &amp;gt;&amp;gt; and &amp;lt;::&amp;gt; that have been fixe=
d in C++11. Another rule could be added for "...", such that 1...2 parses c=
orrectly.<br><br>A slightly weak argument against allowing the range case s=
yntax is that almost certainly it'll be used as "case 'a'...'z'", which wou=
ld be bad, since that range is not necessarily "abcdefghijklmnopqrstuvwxyz"=
..<br><br>More importantly, I don't think there are much use cases for range=
 case labels, since for characters std::is{alpha,digit,....} usually alread=
y provides superior functionality, and for other integral types, an if-stat=
ement with comparison operators is likely more appropriate.<br><br>Did you =
run into a situation where a range case label would make your code better?<=
br><br>-Maurice-<br><br><br><br>Op donderdag 18 juli 2013 16:26:06 UTC+2 sc=
hreef Laszlo Papp het volgende:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>Hi,<div><br></div><div>Perhaps, it has been discussed before, but I have h=
ad a minor issue with the standard for many years now. I have wished to hav=
e a feature for supporting ranges inside switch statements for the cases. A=
s it seems, gcc already has an extension [1] for that.</div><div><br></div>=
<div>What do you think?</div><div><br></div><div>Cheers,</div><div>Laszlo</=
div><div><br></div><div>[1]&nbsp;<a href=3D"http://gcc.gnu.org/onlinedocs/g=
cc-4.1.2/gcc/Case-Ranges.html" target=3D"_blank">http://gcc.gnu.org/<wbr>on=
linedocs/gcc-4.1.2/gcc/Case-<wbr>Ranges.html</a></div></blockquote>

<p></p>

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

------=_Part_11_14624341.1374177800369--

.

--001a11c2ed4a60977804e1cee1d3
Content-Type: text/plain; charset=ISO-8859-1

On 18 July 2013 23:03, Maurice Bos <m-ou.se@m-ou.se> wrote:

> Hey,
>
> I don't really like the '...' syntax they use, since (as they already
> mention on that page) in 1...2, the first token will be '1.', not  '1', and
> things get ugly.
> However, this isn't much different than the problems with &gt;&gt; and
> &lt;::&gt; that have been fixed in C++11. Another rule could be added for
> "...", such that 1...2 parses correctly.
>
> A slightly weak argument against allowing the range case syntax is that
> almost certainly it'll be used as "case 'a'...'z'", which would be bad,
> since that range is not necessarily "abcdefghijklmnopqrstuvwxyz".
>
> More importantly, I don't think there are much use cases for range case
> labels, since for characters std::is{alpha,digit,....} usually already
> provides superior functionality, and for other integral types, an
> if-statement with comparison operators is likely more appropriate.
>
> Did you run into a situation where a range case label would make your code
> better?
>
>
It avoids having to repeat the variable the value of which is tested. Then
again, it's questionable whether
we should have special support for contiguous ranges in a switch, when an
if can do that and more, including
non-contiguous ranges, at the cost of slightly more typing. And if people
want to get serious about new
control structures, they can define a function that takes variadic
arguments that are the values/functors
to test with and the lambdas to run if a value/functor matches. Again, at
the cost of more typing since the
lambdas must be enclosed in the usual lambda introducer and braces. I have
written such a case-construct
that can equal-compare anything, including strings, so you can practically
switch-case strings.

--

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



--001a11c2ed4a60977804e1cee1d3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 18 July 2013 23:03, Maurice Bos <span dir=3D"ltr">&lt;<a href=3D=
"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.se@m-ou.se</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey,<br><br>I don&#39;t really like the &#39=
;...&#39; syntax they use, since (as they already mention on that page) in =
1...2, the first token will be &#39;1.&#39;, not=A0 &#39;1&#39;, and things=
 get ugly.<br>
However, this isn&#39;t much different than the problems with &amp;gt;&amp;=
gt; and &amp;lt;::&amp;gt; that have been fixed in C++11. Another rule coul=
d be added for &quot;...&quot;, such that 1...2 parses correctly.<br><br>
A slightly weak argument against allowing the range case syntax is that alm=
ost certainly it&#39;ll be used as &quot;case &#39;a&#39;...&#39;z&#39;&quo=
t;, which would be bad, since that range is not necessarily &quot;abcdefghi=
jklmnopqrstuvwxyz&quot;.<br>
<br>More importantly, I don&#39;t think there are much use cases for range =
case labels, since for characters std::is{alpha,digit,....} usually already=
 provides superior functionality, and for other integral types, an if-state=
ment with comparison operators is likely more appropriate.<br>
<br>Did you run into a situation where a range case label would make your c=
ode better?<br><br></blockquote><div><br></div><div>It avoids having to rep=
eat the variable the value of which is tested. Then again, it&#39;s questio=
nable whether<br>
we should have special support for contiguous ranges in a switch, when an i=
f can do that and more, including<br></div><div>non-contiguous ranges, at t=
he cost of slightly more typing. And if people want to get serious about ne=
w<br>
control structures, they can define a function that takes variadic argument=
s that are the values/functors<br></div><div>to test with and the lambdas t=
o run if a value/functor matches. Again, at the cost of more typing since t=
he<br>
lambdas must be enclosed in the usual lambda introducer and braces. I have =
written such a case-construct<br>that can equal-compare anything, including=
 strings, so you can practically switch-case strings.<br></div></div><br>
</div></div>

<p></p>

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

--001a11c2ed4a60977804e1cee1d3--

.

How about a generic and an extensible solution. Change case statements to be predicate based.

Let the case "label" for a switch on an object of type T be a constexpr predicate function with the signature

constexpr bool CasePredicate (const T &, ...);

Let there be a default predicate for every type that returns true on equality. This can be overridden so that it could take a range and return true if t was in the range. Another great example would be for even/odd.

I just had this idea and haven't thought it through much, so I'm sure there are still lots of holes in the idea. Thoughts?

--

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



.

------=_Part_419_32352012.1374271611078
Content-Type: text/plain; charset=ISO-8859-1



On Friday, July 19, 2013 5:47:03 AM UTC+2, Michael Price - Dev wrote:
>
> How about a generic and an extensible solution. Change case statements to
> be predicate based.
>
> Let the case "label" for a switch on an object of type T be a constexpr
> predicate function with the signature
>
> constexpr bool CasePredicate (const T &, ...);
>
> Let there be a default predicate for every type that returns true on
> equality. This can be overridden so that it could take a range and return
> true if t was in the range. Another great example would be for even/odd.
>
> I just had this idea and haven't thought it through much, so I'm sure
> there are still lots of holes in the idea. Thoughts?
>
I think better would be some way of transferring variadic template to
switch cases. I have idea of syntax that could do something like that and
still look and behave like C++
template<int... Ints>
void func(int i)
{
    switch(i)
    {
        for...(I : Ints)
        {   //I is `int` that represents n-th element of Ints
            case I: temp<I>::f(); //no break;
            case I+1: temp<I>::h(); break; //this is switch break not
`for...` break
        }
        for...(Ints) //shorthand
        {   //Ints represents now n-th element of Ints in that scope
            case Ints + 1000: temp<Ints>::g(); break;
        }
    }
    for...(Ints)
    {
        foo<Ints>(); //we dont need use recursion to call `foo<1>();
foo<2>(); ...` now
    }
}
template<typename... TT>
void bar()
{
    int i = 42;
    for...(T : TT) //work for typename too
    {
        T j;
        j.f(i)
        std::cout << j << std::endl;
    }
}
this will be keyword overload similar to `sizeof...`. It will behave like
`for` except for `break` and `continue` that will be ignored by this new
`for...`.

--

---
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_419_32352012.1374271611078
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, July 19, 2013 5:47:03 AM UTC+2, Michael Price - Dev wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">How about a generic and an e=
xtensible solution. Change case statements to be predicate based.<p>Let the=
 case "label" for a switch on an object of type T be a constexpr predicate =
function with the signature</p><p>constexpr bool CasePredicate (const T &am=
p;, ...);</p><p>Let there be a default predicate for every type that return=
s true on equality. This can be overridden so that it could take a range an=
d return true if t was in the range. Another great example would be for eve=
n/odd.</p><p>I just had this idea and haven't thought it through much, so I=
'm sure there are still lots of holes in the idea. Thoughts?</p></blockquot=
e><div>I think better would be some way of transferring variadic template t=
o switch cases. I have idea of syntax that could do something like that and=
 still look and behave like C++<br><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ints<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&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-prettify"> func</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">switch</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><sp=
an 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: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">for</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">I </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Ints</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">&nbsp;&nbsp; //I is `int` that represents </spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">n-th=
 element of Ints</span></code></span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><br></span></code></span></code>&=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> I</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><code class=3D"prettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">temp</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">I</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span></code></span></code></span></code><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(); //no break;</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"></span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></cod=
e>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> I</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">+1:</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span></code></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypri=
nt"><span style=3D"color: #000;" class=3D"styled-by-prettify">temp</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">I</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;</span></code></span></code></=
span></code></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span>h<span style=3D"color: #660;" class=3D"styled-by-prettify">();</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> //this is </span></code></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prett=
yprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code cla=
ss=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify=
"></span><span style=3D"color: #008;" class=3D"styled-by-prettify">switch b=
reak not `for...` break<br></span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"></span></code></span></code>&nbsp; &nbsp; &nbsp; &nbsp; </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"pretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">...(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ints</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> //shorthand<br>&nbsp; &nb=
sp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">&=
nbsp;&nbsp; //Ints represents now n-th element of Ints in that scope<br>&nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span></code></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypri=
nt"><span style=3D"color: #660;" class=3D"styled-by-prettify"></span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Ints</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"></span></code></span></code></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"> + 1000:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> temp</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"></span></code></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"pr=
ettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"></span><span style=3D"color: #000;" class=3D"styled-by-prettify"></spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Ints</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"></span></code></span>=
</code></span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">g</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></code>&nbsp; &nbsp; <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;&nbsp;&nbs=
p; for...(Ints)<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; foo&lt;Ints&gt;(); //we dont need use recursion to call `foo&lt;=
1&gt;(); foo&lt;2&gt;(); ...` now<br>&nbsp;&nbsp;&nbsp; }<br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>template&lt;typename... TT&gt=
;<br>void bar()<br>{<br>&nbsp;&nbsp;&nbsp; int i =3D 42;<br>&nbsp;&nbsp;&nb=
sp; for...(T : TT) //work for typename too<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; T j;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; j.f(i)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::cout &lt;&lt;=
 j &lt;&lt; std::endl;<br>&nbsp;&nbsp;&nbsp; }<br>}<br></span></div></code>=
</div>this will be keyword overload similar to `sizeof...`. It will behave =
like `for` except for `break` and `continue` that will be ignored by this n=
ew `for...`. <br><br></div>

<p></p>

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

------=_Part_419_32352012.1374271611078--

.

--f46d043c81a0eb0f3004e1e551fc
Content-Type: text/plain; charset=ISO-8859-1

On 18 July 2013 22:47, Michael Price - Dev <michael.b.price.dev@gmail.com>wrote:

> How about a generic and an extensible solution. Change case statements to
> be predicate based.
>

Then it becomes either (a) order dependent, (b) you have to check all the
predicates or (c) really weird bugs.

-1.  I haven't seen nearly enough justification that this is worth the cost.
--
 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/.



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

On 18 July 2013 22:47, Michael Price - Dev <span dir=3D"ltr">&lt;<a href=3D=
"mailto:michael.b.price.dev@gmail.com" target=3D"_blank">michael.b.price.de=
v@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

How about a generic and an extensible solution. Change case statements to b=
e predicate based.<br></blockquote><div><br>Then it becomes either (a) orde=
r dependent, (b) you have to check all the predicates or (c) really weird b=
ugs.<br>

<br>-1.=A0 I haven&#39;t seen nearly enough justification that this is wort=
h the cost.<br></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mai=
lto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>&gt;=A0 (847) 691-1404

<p></p>

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

--f46d043c81a0eb0f3004e1e551fc--

.

--bcaec5304f81e232f204e1d266ed
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 18, 2013 at 9:16 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 18 July 2013 23:03, Maurice Bos <m-ou.se@m-ou.se> wrote:
>
>> Hey,
>>
>> I don't really like the '...' syntax they use, since (as they already
>> mention on that page) in 1...2, the first token will be '1.', not  '1', and
>> things get ugly.
>> However, this isn't much different than the problems with &gt;&gt; and
>> &lt;::&gt; that have been fixed in C++11. Another rule could be added for
>> "...", such that 1...2 parses correctly.
>>
>> A slightly weak argument against allowing the range case syntax is that
>> almost certainly it'll be used as "case 'a'...'z'", which would be bad,
>> since that range is not necessarily "abcdefghijklmnopqrstuvwxyz".
>>
>> More importantly, I don't think there are much use cases for range case
>> labels, since for characters std::is{alpha,digit,....} usually already
>> provides superior functionality, and for other integral types, an
>> if-statement with comparison operators is likely more appropriate.
>>
>> Did you run into a situation where a range case label would make your
>> code better?
>>
>>
> It avoids having to repeat the variable the value of which is tested.
>

Yes.


> Then again, it's questionable whether
> we should have special support for contiguous ranges in a switch, when an
> if can do that and more, including
> non-contiguous ranges, at the cost of slightly more typing.
>

You could say that about switch as a whole. You can achieve everything with
if... it is just convenience after all.


> And if people want to get serious about new
> control structures, they can define a function that takes variadic
> arguments that are the values/functors
> to test with and the lambdas to run if a value/functor matches. Again, at
> the cost of more typing since the
> lambdas must be enclosed in the usual lambda introducer and braces. I have
> written such a case-construct
> that can equal-compare anything, including strings, so you can practically
> switch-case strings.
>

Same as above as you also wrote it is more typing. Also, you seem to have
used this, so it is probably not that uncommon, then.

Cheers,
Laszlo

--

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



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Thu, Jul 18, 2013 at 9:16 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"color:rgb(80=
,0,80)">On 18 July 2013 23:03, Maurice Bos </span><span dir=3D"ltr" style=
=3D"color:rgb(80,0,80)">&lt;<a href=3D"mailto:m-ou.se@m-ou.se" target=3D"_b=
lank">m-ou.se@m-ou.se</a>&gt;</span><span style=3D"color:rgb(80,0,80)"> wro=
te:</span><br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hey,<br><br>I don&#39;t really like the &#39=
;...&#39; syntax they use, since (as they already mention on that page) in =
1...2, the first token will be &#39;1.&#39;, not=A0 &#39;1&#39;, and things=
 get ugly.<br>

However, this isn&#39;t much different than the problems with &amp;gt;&amp;=
gt; and &amp;lt;::&amp;gt; that have been fixed in C++11. Another rule coul=
d be added for &quot;...&quot;, such that 1...2 parses correctly.<br><br>

A slightly weak argument against allowing the range case syntax is that alm=
ost certainly it&#39;ll be used as &quot;case &#39;a&#39;...&#39;z&#39;&quo=
t;, which would be bad, since that range is not necessarily &quot;abcdefghi=
jklmnopqrstuvwxyz&quot;.<br>

<br>More importantly, I don&#39;t think there are much use cases for range =
case labels, since for characters std::is{alpha,digit,....} usually already=
 provides superior functionality, and for other integral types, an if-state=
ment with comparison operators is likely more appropriate.<br>

<br>Did you run into a situation where a range case label would make your c=
ode better?<br><br></blockquote><div><br></div></div><div>It avoids having =
to repeat the variable the value of which is tested.</div></div></div>
</div></blockquote><div><br></div><div>Yes.</div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<div>Then again, it&#39;s questionable whether<br>
we should have special support for contiguous ranges in a switch, when an i=
f can do that and more, including<br></div><div>non-contiguous ranges, at t=
he cost of slightly more typing.</div></div></div></div></blockquote><div>
<br></div><div>You could say that about switch as a whole. You can achieve =
everything with if... it is just convenience after all.</div><div>=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>And if people want to get serious about new<br>
control structures, they can define a function that takes variadic argument=
s that are the values/functors<br></div><div>to test with and the lambdas t=
o run if a value/functor matches. Again, at the cost of more typing since t=
he<br>

lambdas must be enclosed in the usual lambda introducer and braces. I have =
written such a case-construct<br>that can equal-compare anything, including=
 strings, so you can practically switch-case strings.<br></div></div></div>
</div></blockquote><div><br></div><div>Same as above as you also wrote it i=
s more typing. Also, you seem to have used this, so it is probably not that=
 uncommon, then.</div><div><br></div><div>Cheers,</div><div>Laszlo</div>
</div></div></div>

<p></p>

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

--bcaec5304f81e232f204e1d266ed--

.

--047d7bd9037c8d27ad04e1d6cae6
Content-Type: text/plain; charset=ISO-8859-1

This reads like a different use case to me which can indeed include the
original request, but would not make that any easier to type than just
using the previously suggested "if"s.


On Fri, Jul 19, 2013 at 4:47 AM, Michael Price - Dev <
michael.b.price.dev@gmail.com> wrote:

> How about a generic and an extensible solution. Change case statements to
> be predicate based.
>
> Let the case "label" for a switch on an object of type T be a constexpr
> predicate function with the signature
>
> constexpr bool CasePredicate (const T &, ...);
>
> Let there be a default predicate for every type that returns true on
> equality. This can be overridden so that it could take a range and return
> true if t was in the range. Another great example would be for even/odd.
>
> I just had this idea and haven't thought it through much, so I'm sure
> there are still lots of holes in the idea. Thoughts?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>

--

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



--047d7bd9037c8d27ad04e1d6cae6
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">This reads like a different use case to me which can indeed include the original request, but would not make that any easier to type than just using the previously suggested &quot;if&quot;s.</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 4:47 AM, Michael Price - Dev <span dir="ltr">&lt;<a href="mailto:michael.b.price.dev@gmail.com" target="_blank">michael.b.price.dev@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How about a generic and an extensible solution. Change case statements to be predicate based.<br>
<br>
Let the case &quot;label&quot; for a switch on an object of type T be a constexpr predicate function with the signature<br>
<br>
constexpr bool CasePredicate (const T &amp;, ...);<br>
<br>
Let there be a default predicate for every type that returns true on equality. This can be overridden so that it could take a range and return true if t was in the range. Another great example would be for even/odd.<br>
<br>
I just had this idea and haven&#39;t thought it through much, so I&#39;m sure there are still lots of holes in the idea. Thoughts?<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/" target="_blank">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
<br>
<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7bd9037c8d27ad04e1d6cae6--

.

--001a11c339e88f7a8804e1e6f30c
Content-Type: text/plain; charset=ISO-8859-1

On 19 July 2013 03:28, Laszlo Papp <lpapp@kde.org> wrote:

>
>
>
>> Then again, it's questionable whether
>> we should have special support for contiguous ranges in a switch, when an
>> if can do that and more, including
>> non-contiguous ranges, at the cost of slightly more typing.
>>
>
> You could say that about switch as a whole. You can achieve everything
> with if... it is just convenience after all.
>

There have been historical cases where a switch has been more efficient,
due to the ability of an implementation
to optimize it into jump tables. I fail to see how that's possible with
ranges.


>
>
>> And if people want to get serious about new
>> control structures, they can define a function that takes variadic
>> arguments that are the values/functors
>> to test with and the lambdas to run if a value/functor matches. Again, at
>> the cost of more typing since the
>> lambdas must be enclosed in the usual lambda introducer and braces. I
>> have written such a case-construct
>> that can equal-compare anything, including strings, so you can
>> practically switch-case strings.
>>
>
> Same as above as you also wrote it is more typing. Also, you seem to have
> used this, so it is probably not that uncommon, then.
>
>
>
I have used such control structures in other programming languages like
Common Lisp, and the prototypes
I've written with c++11 have been mostly experimental, not something that I
have used or considered
using in practice. At any rate, it would perhaps be useful to explore such
approaches before
considering a core language change.

--

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



--001a11c339e88f7a8804e1e6f30c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 19 July 2013 03:28, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br>=A0<div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Then again, it&#39;s questionable whether<br>
we should have special support for contiguous ranges in a switch, when an i=
f can do that and more, including<br></div><div>non-contiguous ranges, at t=
he cost of slightly more typing.</div></div></div></div></blockquote><div>

<br></div></div><div>You could say that about switch as a whole. You can ac=
hieve everything with if... it is just convenience after all.</div></div></=
div></div></blockquote><div><br></div><div>There have been historical cases=
 where a switch has been more efficient, due to the ability of an implement=
ation<br>
to optimize it into jump tables. I fail to see how that&#39;s possible with=
 ranges.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra">
<div class=3D"gmail_quote"><div class=3D"im"><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>And if people want to get serious about new<br>
control structures, they can define a function that takes variadic argument=
s that are the values/functors<br></div><div>to test with and the lambdas t=
o run if a value/functor matches. Again, at the cost of more typing since t=
he<br>


lambdas must be enclosed in the usual lambda introducer and braces. I have =
written such a case-construct<br>that can equal-compare anything, including=
 strings, so you can practically switch-case strings.<br></div></div></div>

</div></blockquote><div><br></div></div><div>Same as above as you also wrot=
e it is more typing. Also, you seem to have used this, so it is probably no=
t that uncommon, then.</div><div><br><br></div></div></div></div></blockquo=
te>
<div><br></div><div>I have used such control structures in other programmin=
g languages like Common Lisp, and the prototypes<br></div><div>I&#39;ve wri=
tten with c++11 have been mostly experimental, not something that I have us=
ed or considered<br>
using in practice. At any rate, it would perhaps be useful to explore such =
approaches before<br></div><div>considering a core language change. <br></d=
iv></div><br></div></div>

<p></p>

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

--001a11c339e88f7a8804e1e6f30c--

.

------=_Part_1705_12151302.1374334037095
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, July 20, 2013 2:59:11 AM UTC+2, Ville Voutilainen wrote:

> You could say that about switch as a whole. You can achieve everything
> with if... it is just convenience after all.
>
> There have been historical cases where a switch has been more efficient,
> due to the ability of an implementation
> to optimize it into jump tables. I fail to see how that's possible with
> ranges.
>

If one can optimize case 0: case 1: case 2: case 3: case 4: case 5: case 6:
case 7: case 8: case 9: do_something(); break;
then why would one not be able to optimize case 0 ... 9: ?

--

---
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_1705_12151302.1374334037095
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, July 20, 2013 2:59:11 AM UTC+2, Ville Voutilainen wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">You could say t=
hat about switch as a whole. You can achieve everything with if... it is ju=
st convenience after all.<br><div><div class=3D"gmail_quote"><div><br></div=
><div>There have been historical cases where a switch has been more efficie=
nt, due to the ability of an implementation<br>
to optimize it into jump tables. I fail to see how that's possible with ran=
ges.<br></div></div></div></div></blockquote><div><br></div><div>If one can=
 optimize&nbsp;case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</div><div>then why would one not=
 be able to optimize case 0 ... 9: ?</div>

<p></p>

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

------=_Part_1705_12151302.1374334037095--

.

--047d7b5d5f32a5340804e1f33927
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 20, 2013 at 4:27 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Saturday, July 20, 2013 2:59:11 AM UTC+2, Ville Voutilainen wrote:
>
>> You could say that about switch as a whole. You can achieve everything
>> with if... it is just convenience after all.
>>
>> There have been historical cases where a switch has been more efficient,
>> due to the ability of an implementation
>> to optimize it into jump tables. I fail to see how that's possible with
>> ranges.
>>
>
> If one can optimize case 0: case 1: case 2: case 3: case 4: case 5: case
> 6: case 7: case 8: case 9: do_something(); break;
>

That, typed out, just shows me again how error-prone that syntax is, i.e.
what we have now. I can easily forget to mention one or more cases which
might cause a hard to debug issue.

Then, there is the issue of static analyzers yielding false positives
without break statements, although that could probably be fixed with
additional logic on their side.

Laszlo

--

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



--047d7b5d5f32a5340804e1f33927
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Jul 20, 2013 at 4:27 PM, Olaf van der Spek <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">ol=
afvdspek@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Saturday, July 20, 2013=
 2:59:11 AM UTC+2, Ville Voutilainen wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">
<div dir=3D"ltr">You could say that about switch as a whole. You can achiev=
e everything with if... it is just convenience after all.<br><div><div clas=
s=3D"gmail_quote"><div><br></div><div>There have been historical cases wher=
e a switch has been more efficient, due to the ability of an implementation=
<br>

to optimize it into jump tables. I fail to see how that&#39;s possible with=
 ranges.<br></div></div></div></div></blockquote><div><br></div></div><div>=
If one can optimize=A0case 0: case 1: case 2: case 3: case 4: case 5: case =
6: case 7: case 8: case 9: do_something(); break;</div>
</blockquote><div><br></div><div>That, typed out, just shows me again how e=
rror-prone that syntax is, i.e. what we have now. I can easily forget to me=
ntion one or more cases which might cause a hard to debug issue.</div><div>
<br></div><div>Then, there is the issue of static analyzers yielding false =
positives without break statements, although that could probably be fixed w=
ith additional logic on their side.</div><div><br></div><div>Laszlo</div>
</div><br></div></div>

<p></p>

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

--047d7b5d5f32a5340804e1f33927--

.

--047d7b5d954971c7a704e251db0a
Content-Type: text/plain; charset=ISO-8859-1

So, Ville, we are still waiting for you to elaborate about the jump table
optimization and why it would not be possible with ranges.


On Sat, Jul 20, 2013 at 4:37 PM, Laszlo Papp <lpapp@kde.org> wrote:

> On Sat, Jul 20, 2013 at 4:27 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:
>
>> On Saturday, July 20, 2013 2:59:11 AM UTC+2, Ville Voutilainen wrote:
>>
>>> You could say that about switch as a whole. You can achieve everything
>>> with if... it is just convenience after all.
>>>
>>> There have been historical cases where a switch has been more efficient,
>>> due to the ability of an implementation
>>> to optimize it into jump tables. I fail to see how that's possible with
>>> ranges.
>>>
>>
>> If one can optimize case 0: case 1: case 2: case 3: case 4: case 5: case
>> 6: case 7: case 8: case 9: do_something(); break;
>>
>
> That, typed out, just shows me again how error-prone that syntax is, i.e.
> what we have now. I can easily forget to mention one or more cases which
> might cause a hard to debug issue.
>
> Then, there is the issue of static analyzers yielding false positives
> without break statements, although that could probably be fixed with
> additional logic on their side.
>
> Laszlo
>
>

--

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



--047d7b5d954971c7a704e251db0a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">So, Ville, we are still waiting for you to elaborate about=
 the jump table optimization and why it would not be possible with ranges.<=
/div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, =
Jul 20, 2013 at 4:37 PM, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im">On Sat, J=
ul 20, 2013 at 4:27 PM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"=
mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;=
</span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"i=
m">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Saturday, July 20, 2013 2:59:11 AM U=
TC+2, Ville Voutilainen wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>

<div dir=3D"ltr">You could say that about switch as a whole. You can achiev=
e everything with if... it is just convenience after all.<br><div><div clas=
s=3D"gmail_quote"><div><br></div><div>There have been historical cases wher=
e a switch has been more efficient, due to the ability of an implementation=
<br>


to optimize it into jump tables. I fail to see how that&#39;s possible with=
 ranges.<br></div></div></div></div></blockquote><div><br></div></div><div>=
If one can optimize=A0case 0: case 1: case 2: case 3: case 4: case 5: case =
6: case 7: case 8: case 9: do_something(); break;</div>

</blockquote><div><br></div></div><div>That, typed out, just shows me again=
 how error-prone that syntax is, i.e. what we have now. I can easily forget=
 to mention one or more cases which might cause a hard to debug issue.</div=
>
<div>
<br></div><div>Then, there is the issue of static analyzers yielding false =
positives without break statements, although that could probably be fixed w=
ith additional logic on their side.</div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div>
<br></div><div>Laszlo</div>
</font></span></div><br></div></div>
</blockquote></div><br></div>

<p></p>

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

--047d7b5d954971c7a704e251db0a--

.

--001a11c2c0eca24e9004e251e7e8
Content-Type: text/plain; charset=ISO-8859-1

On 25 July 2013 11:31, Laszlo Papp <lpapp@kde.org> wrote:

> So, Ville, we are still waiting for you to elaborate about the jump table
> optimization and why it would not be possible with ranges.
>
>
>
You are? Ok. For a range of a handful of numbers, it's possible. Do you
think an implementation can do it for
a range of thousand ints?

I'm still waiting for someone to elaborate why this feature proposal would
be worth its costs.

--

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



--001a11c2c0eca24e9004e251e7e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 July 2013 11:31, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">So, Ville, we are still waiting for you to elaborate about=
 the jump table optimization and why it would not be possible with ranges.<=
/div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br=
><br>
</div></div></div></blockquote><div><br></div><div>You are? Ok. For a range=
 of a handful of numbers, it&#39;s possible. Do you think an implementation=
 can do it for<br>a range of thousand ints?<br><br></div><div>I&#39;m still=
 waiting for someone to elaborate why this feature proposal would be worth =
its costs. <br>
</div></div><br></div></div>

<p></p>

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

--001a11c2c0eca24e9004e251e7e8--

.

--047d7b0721ca47647104e2528d02
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 25, 2013 at 9:35 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 25 July 2013 11:31, Laszlo Papp <lpapp@kde.org> wrote:
>
>> So, Ville, we are still waiting for you to elaborate about the jump table
>> optimization and why it would not be possible with ranges.
>>
>>
>>
> You are? Ok. For a range of a handful of numbers, it's possible. Do you
> think an implementation can do it for
> a range of thousand ints?
>

Even if that is true which I cannot be sure unfortunately, what would you
lose to the situation now? You could not be any slower than now because you
would fall back to ifs anyway. However, for the cases with a handful of
numbers, it would still be optimized then.


> I'm still waiting for someone to elaborate why this feature proposal would
> be worth its costs.
>

It results a more readable code than this:

case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
case 9: do_something(); break;

But yes, there are other problems with the switch statement in C++.
Perhaps, we should introduce a new structure where "case" and "break" are
unnecessary, and it could support ranges, merges for several, but
non-continuous values?

Laszlo

--

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



--047d7b0721ca47647104e2528d02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jul 25, 2013 at 9:35 AM, Ville Voutilainen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=
=3D"gmail_extra">
<br><br><div class=3D"gmail_quote"><div class=3D"im">On 25 July 2013 11:31,=
 Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D"mailto:lpapp@kde.org" target=
=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr">So, Ville, we are still waiting for you to elaborate about=
 the jump table optimization and why it would not be possible with ranges.<=
/div><div><div><div class=3D"gmail_extra"><br><br>
</div></div></div></blockquote><div><br></div></div><div>You are? Ok. For a=
 range of a handful of numbers, it&#39;s possible. Do you think an implemen=
tation can do it for<br>a range of thousand ints?<br></div></div></div>
</div></blockquote><div><br></div><div>Even if that is true which I cannot =
be sure unfortunately, what would you lose to the situation now? You could =
not be any slower than now because you would fall back to ifs anyway. Howev=
er, for the cases with a handful of numbers, it would still be optimized th=
en.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<div>I&#39;m still waiting for someone to elaborate why this feature propos=
al would be worth its costs.=A0<br></div></div></div></div></blockquote><di=
v><br></div><div>It results a more readable code than this:</div><div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div><div><br></div><div>
But yes, there are other problems with the switch statement in C++. Perhaps=
, we should introduce a new structure where &quot;case&quot; and &quot;brea=
k&quot; are unnecessary, and it could support ranges, merges for several, b=
ut non-continuous values?</div>
<div><br></div><div>Laszlo</div></div></div></div>

<p></p>

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

--047d7b0721ca47647104e2528d02--

.

--20cf306844d591217704e2535922
Content-Type: text/plain; charset=ISO-8859-1

On 25 July 2013 12:21, Laszlo Papp <lpapp@kde.org> wrote:

>
>
>
>> I'm still waiting for someone to elaborate why this feature proposal
>> would be worth its costs.
>>
>
> It results a more readable code than this:
>
> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
> case 9: do_something(); break;
>

Yeah, then I guess I'm still waiting, since you could just write that with
a single if and get much more readable
code.

Do people consider this readable?

  range_switch(6,
           range_case(1,3),
               [](){std::cout << "[1,3)" << std::endl;},
           range_case(4,7),
               [](){std::cout << "[4,7)" << std::endl;});



>
> But yes, there are other problems with the switch statement in C++.
> Perhaps, we should introduce a new structure where "case" and "break" are
> unnecessary, and it could support ranges, merges for several, but
> non-continuous values?
>
>
>
Perhaps we can already write such structures without core language changes.

--

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



--20cf306844d591217704e2535922
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 July 2013 12:21, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br>=A0<div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div>I&#39;m still waiting for someone to elaborate why this feature propos=
al would be worth its costs.=A0<br></div></div></div></div></blockquote><di=
v><br></div></div><div>It results a more readable code than this:</div><div=
 class=3D"im">
<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>
</div></blockquote><div><br></div><div>Yeah, then I guess I&#39;m still wai=
ting, since you could just write that with a single if and get much more re=
adable<br>code.<br><br></div><div>Do people consider this readable?<br>
<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(1,3), <b=
r>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1=
,3)&quot; &lt;&lt; std::endl;},<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(=
4,7), <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; =
&quot;[4,7)&quot; &lt;&lt; std::endl;});<br>
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=
=3D"im"><div>
<br></div></div><div>
But yes, there are other problems with the switch statement in C++. Perhaps=
, we should introduce a new structure where &quot;case&quot; and &quot;brea=
k&quot; are unnecessary, and it could support ranges, merges for several, b=
ut non-continuous values?</div>
<span class=3D""><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div><div>Perhaps we can already write such structures without core language=
 changes. <br></div></div><br></div></div>

<p></p>

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

--20cf306844d591217704e2535922--

.

--001a11c3a9687f0e9504e253900d
Content-Type: text/plain; charset=ISO-8859-1

2013/7/25 Ville Voutilainen <ville.voutilainen@gmail.com>

>
>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
>> case 9: do_something(); break;
>>
>
> Yeah, then I guess I'm still waiting, since you could just write that with
> a single if and get much more readable
> code.
>
> Do people consider this readable?
>
>   range_switch(6,
>            range_case(1,3),
>                [](){std::cout << "[1,3)" << std::endl;},
>            range_case(4,7),
>                [](){std::cout << "[4,7)" << std::endl;});
>
>
> Perhaps we can already write such structures without core language
> changes.
>
>

Indeed, there seem to be plenty of ways in which such things can already be
done in C++.

Another option, for example: You could go for using a simple if with some
helper type for ranges, to avoid having to make lambdas. Something like:

range_checker r(6);
if (r(1,3)) {
    std::cout << "[1,3)" << std::endl;
} else if (r(4,7)) {
    std::cout << "[4,7)" << std::endl;
}

(However, the disadvantage here is that can't check that the cases don't
overlap.)

--

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



--001a11c3a9687f0e9504e253900d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">2013/7/25 Ville Voutilainen <span dir=3D"ltr=
">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vill=
e.voutilainen@gmail.com</a>&gt;</span><br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra">

<div class=3D"gmail_quote"><div>
<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>


</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br><br></div><div>Do people consider this readable?<b=
r>


<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(1,3), <b=
r>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1=
,3)&quot; &lt;&lt; std::endl;},<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(=
4,7), <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; =
&quot;[4,7)&quot; &lt;&lt; std::endl;});<br>


<br><div class=3D"im"><div><br></div></div><div>Perhaps we can already writ=
e such structures without core language changes. <br></div>=A0</div></div><=
/div></div></blockquote><div><br>Indeed, there seem to be plenty of ways in=
 which such things can already be done in C++.<br>

<br>Another option, for example: You could go for using a simple if with so=
me helper type for ranges, to avoid having to make lambdas. Something like:=
<br><br>range_checker r(6);<br>if (r(1,3)) {<br>=A0=A0=A0 std::cout &lt;&lt=
; &quot;[1,3)&quot; &lt;&lt; std::endl;<br>

} else if (r(4,7)) {<br>=A0=A0=A0 std::cout &lt;&lt; &quot;[4,7)&quot; &lt;=
&lt; std::endl;<br>}<br><br>(However, the disadvantage here is that can&#39=
;t check that the cases don&#39;t overlap.)<br>=A0</div></div>

<p></p>

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

--001a11c3a9687f0e9504e253900d--

.

--089e013cbae8a6633904e2539f0b
Content-Type: text/plain; charset=ISO-8859-1

On 25 July 2013 13:33, Maurice Bos <m-ou.se@m-ou.se> wrote:

>
> 2013/7/25 Ville Voutilainen <ville.voutilainen@gmail.com>
>
>>
>>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
>>> case 9: do_something(); break;
>>>
>>
>> Yeah, then I guess I'm still waiting, since you could just write that
>> with a single if and get much more readable
>> code.
>>
>> Do people consider this readable?
>>
>>   range_switch(6,
>>            range_case(1,3),
>>                [](){std::cout << "[1,3)" << std::endl;},
>>            range_case(4,7),
>>                [](){std::cout << "[4,7)" << std::endl;});
>>
>>
>> Perhaps we can already write such structures without core language
>> changes.
>>
>>
>
> Indeed, there seem to be plenty of ways in which such things can already
> be done in C++.
>
> Another option, for example: You could go for using a simple if with some
> helper type for ranges, to avoid having to make lambdas.
>
>
For what it's worth, I can (and just did) make it look like this:

  range_switch(6,
           rcase(1,3, {
               std::cout << "[1,3)" << std::endl;
           }),
           rcase(4,7, {
               std::cout << "[4,7)" << std::endl;
           }));

Changing the case so that the case-range is again re-parenthesized isn't a
big stretch either. The former
example was a variadic template with lambdas, I have another non-template
that takes an initializer list of
tuples of range values + lambda, this last one has a macro in the
implementation. All of these are pure
library implementations.

--

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



--089e013cbae8a6633904e2539f0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 July 2013 13:33, Maurice Bos <span dir=3D"ltr">&lt;<a href=3D=
"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.se@m-ou.se</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class=3D"gmail_q=
uote">2013/7/25 Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:v=
ille.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</=
a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">
<div class=3D"gmail_extra">

<div class=3D"gmail_quote"><div>
<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>



</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br><br></div></div><div><div class=3D"im">Do people c=
onsider this readable?<br>



<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(1,3), <b=
r>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1=
,3)&quot; &lt;&lt; std::endl;},<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(=
4,7), <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; =
&quot;[4,7)&quot; &lt;&lt; std::endl;});<br>



<br><div><div><br></div></div></div><div class=3D"im"><div>Perhaps we can a=
lready write such structures without core language changes. <br></div>=A0</=
div></div></div></div></div></blockquote><div><br>Indeed, there seem to be =
plenty of ways in which such things can already be done in C++.<br>


<br>Another option, for example: You could go for using a simple if with so=
me helper type for ranges, to avoid having to make lambdas.<br><br></div></=
div></blockquote><div><br></div><div>For what it&#39;s worth, I can (and ju=
st did) make it look like this:<br>
<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 rcase(1,3, {<br>=A0=
=A0=A0 =A0=A0 =A0=A0=A0=A0=A0=A0=A0 std::cout &lt;&lt; &quot;[1,3)&quot; &l=
t;&lt; std::endl;<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 }),<br>=A0=A0=A0 =A0=A0=
=A0=A0=A0=A0 rcase(4,7, { <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 std:=
:cout &lt;&lt; &quot;[4,7)&quot; &lt;&lt; std::endl;<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }));<br>=A0<br></div><div>Changing the case =
so that the case-range is again re-parenthesized isn&#39;t a big stretch ei=
ther. The former<br>example was a variadic template with lambdas, I have an=
other non-template that takes an initializer list of <br>
tuples of range values + lambda, this last one has a macro in the implement=
ation. All of these are pure<br>library implementations.<br></div></div></d=
iv></div>

<p></p>

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

--089e013cbae8a6633904e2539f0b--

.

On Thu, Jul 25, 2013 at 12:38 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> For what it's worth, I can (and just did) make it look like this:
>
>   range_switch(6,
>            rcase(1,3, {
>
>                std::cout << "[1,3)" << std::endl;
>            }),
>            rcase(4,7, {
>                std::cout << "[4,7)" << std::endl;
>            }));

range_switch(6,
  rcase(1,3, { std::cout << "[1,3)" << std::endl; }),
  rcase(4,7, { std::cout << "[4,7)" << std::endl; })
);

vs

switch (6)
{
  case 1 .. 3: std::cout << "[1,3)" << std::endl; break;
  case 4 .. 7: std::cout << "[4,7)" << std::endl; break;
}

Not too bad. Though it does add new syntax for little reason and
doesn't support fall through.
How's compile-time and run-time performance? And potential error messages?

--

---
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 Thu, Jul 25, 2013 at 12:38 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> For what it's worth, I can (and just did) make it look like this:
>
>   range_switch(6,
>            rcase(1,3, {
>
>                std::cout << "[1,3)" << std::endl;
>            }),
>            rcase(4,7, {
>                std::cout << "[4,7)" << std::endl;
>            }));
>

Didn't you forget the [] lambda introducers?

Mit freundlichen Gr=FC=DFen,

Martinho

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



.

--001a11c37cac0914bd04e25446cf
Content-Type: text/plain; charset=ISO-8859-1

> >
> > For what it's worth, I can (and just did) make it look like this:
> >
> >   range_switch(6,
> >            rcase(1,3, {
> >
> >                std::cout << "[1,3)" << std::endl;
> >            }),
> >            rcase(4,7, {
> >                std::cout << "[4,7)" << std::endl;
> >            }));
> >
>
> Didn't you forget the [] lambda introducers?
>
>
The solution used macro's to avoid that.

With macro's you can go quite far. You could even make this working:

range_switch(6,
    (1, 3)( std::cout << "asdf" << std::endl; )
    (4, 10)( std::cout << "blah" << std::endl; )
)

(Using macro's with an expansion of which the last token is again a name of
a similar macro, such that it can be invoked again directly by another set
of parenthesis.)

--

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



--001a11c37cac0914bd04e25446cf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D=
"im">
&gt;<br>
&gt; For what it&#39;s worth, I can (and just did) make it look like this:<=
br>
&gt;<br>
&gt; =A0 range_switch(6,<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0rcase(1,3, {<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0std::cout &lt;&lt; &quot;[1,3)&quot; &l=
t;&lt; std::endl;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0}),<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0rcase(4,7, {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0std::cout &lt;&lt; &quot;[4,7)&quot; &l=
t;&lt; std::endl;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0}));<br>
&gt;<br>
<br>
</div>Didn&#39;t you forget the [] lambda introducers?<br>
<br></blockquote><div><br>The solution used macro&#39;s to avoid that.<br><=
br>With macro&#39;s you can go quite far. You could even make this working:=
<br><br>range_switch(6,<br>=A0=A0=A0 (1, 3)( std::cout &lt;&lt; &quot;asdf&=
quot; &lt;&lt; std::endl; )<br>

=A0=A0=A0 (4, 10)( std::cout &lt;&lt; &quot;blah&quot; &lt;&lt; std::endl; =
)<br>)<br><br>(Using macro&#39;s with an expansion of which the last token =
is again a name of a similar macro, such that it can be invoked again direc=
tly by another set of parenthesis.)<br>

</div></div>

<p></p>

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

--001a11c37cac0914bd04e25446cf--

.

--001a113318ce3840a104e254a15d
Content-Type: text/plain; charset=ISO-8859-1

On 25 July 2013 13:44, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> Not too bad. Though it does add new syntax for little reason and
> doesn't support fall through.
> How's compile-time and run-time performance? And potential error messages?
>

It boils down to a recursive template that performs a series of ifs. The
initializer_list
version does a for loop over the list. The error messages are unfortunately
ghastly, and the plumbing is not novice-friendly to write compared to a
simple
ranged case-label.

--

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



--001a113318ce3840a104e254a15d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 July 2013 13:44, Olaf van der Spek <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Not too bad. Though it does add new syntax f=
or little reason and<br>
doesn&#39;t support fall through.<br>
How&#39;s compile-time and run-time performance? And potential error messag=
es?<br></blockquote><div><br></div><div>It boils down to a recursive templa=
te that performs a series of ifs. The initializer_list<br>version does a fo=
r loop over the list. The error messages are unfortunately<br>
ghastly, and the plumbing is not novice-friendly to write compared to a sim=
ple<br>ranged case-label.<br></div></div></div></div>

<p></p>

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

--001a113318ce3840a104e254a15d--

.

--047d7bdc9396d6d32104e254acb7
Content-Type: text/plain; charset=ISO-8859-1

On 25 July 2013 14:24, Maurice Bos <m-ou.se@m-ou.se> wrote:

>
> >
>> > For what it's worth, I can (and just did) make it look like this:
>> >
>> >   range_switch(6,
>> >            rcase(1,3, {
>> >
>> >                std::cout << "[1,3)" << std::endl;
>> >            }),
>> >            rcase(4,7, {
>> >                std::cout << "[4,7)" << std::endl;
>> >            }));
>> >
>>
>> Didn't you forget the [] lambda introducers?
>>
>>
> The solution used macro's to avoid that.
>

Yep. I didn't forget the lambda-introducers because I hid them. The code
was rudimentarily tested.
These were two-minute hacks. I'll paste them here for curious people.

template version with a lambda-introducer-hiding macro:

#include <iostream>
#include <utility>

template<class T> void range_switch(int val, std::pair<int, int> range,
                T func)
{
  if (val >= range.first && val < range.second) {
    func();
  }
}

template<class T, class... U> void range_switch(int val, std::pair<int,
int> range,
                        T func, U... rest)
{
  if (val >= range.first && val < range.second) {
    func();
    return;
  }
  range_switch(val, rest...);
}

template <class T, class U> auto range_case(T&& t, U&&u) ->
decltype(std::make_pair(std::forward<T>(t), std::forward<U>(u))) {
  return std::make_pair(std::forward<T>(t), std::forward<U>(u));
}

#define rcase(a, b, c) range_case((a), (b)), []()c
int main()
{
  range_switch(6,
           rcase(1,3, {
           std::cout << "[1,3)" << std::endl;
           }),
           rcase(4,7, {
               std::cout << "[4,7)" << std::endl;
               }));

}


Initializer-list version:

#include <iostream>
#include <utility>
#include <tuple>
#include <initializer_list>
#include <functional>


void range_switch(int val, std::initializer_list<std::tuple<int, int,
std::function<void()>>> cases)
{
  for (const auto& i : cases) {
    if (val >= std::get<0>(i) && val < std::get<1>(i)) {
      std::get<2>(i)();
      break;
    }
  }
}

template <class... Args> auto range_case(Args&&... args)
  -> decltype(std::make_tuple(std::forward<Args>(args)...)) {
  return std::make_tuple(std::forward<Args>(args)...);
}

int main()
{
  range_switch(6, {
      range_case(1,3,
          [](){std::cout << "[1,3)" << std::endl;}),
      range_case(4,7,
          [](){std::cout << "[4,7)" << std::endl;})
  });
}

--

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



--047d7bdc9396d6d32104e254acb7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 July 2013 14:24, Maurice Bos <span dir=3D"ltr">&lt;<a href=3D=
"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.se@m-ou.se</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class=3D"gmail_q=
uote"><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
&gt;<br>
&gt; For what it&#39;s worth, I can (and just did) make it look like this:<=
br>
&gt;<br>
&gt; =A0 range_switch(6,<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0rcase(1,3, {<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0std::cout &lt;&lt; &quot;[1,3)&quot; &l=
t;&lt; std::endl;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0}),<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0rcase(4,7, {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0std::cout &lt;&lt; &quot;[4,7)&quot; &l=
t;&lt; std::endl;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0}));<br>
&gt;<br>
<br>
</div>Didn&#39;t you forget the [] lambda introducers?<br>
<br></blockquote></div><div><br>The solution used macro&#39;s to avoid that=
..<br></div></div></blockquote><div><br></div><div>Yep. I didn&#39;t forget =
the lambda-introducers because I hid them. The code was rudimentarily teste=
d.<br>
These were two-minute hacks. I&#39;ll paste them here for curious people.<b=
r><br></div><div>template version with a lambda-introducer-hiding macro:<br=
><br>#include &lt;iostream&gt;<br>#include &lt;utility&gt;<br><br>template&=
lt;class T&gt; void range_switch(int val, std::pair&lt;int, int&gt; range,<=
br>
=A0=A0=A0 =A0=A0 =A0=A0=A0 =A0=A0=A0 =A0T func)<br>{<br>=A0 if (val &gt;=3D=
 range.first &amp;&amp; val &lt; range.second) {<br>=A0=A0=A0 func();<br>=
=A0 }<br>}<br><br>template&lt;class T, class... U&gt; void range_switch(int=
 val, std::pair&lt;int, int&gt; range,<br>
=A0=A0=A0 =A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=A0 T func, U... re=
st)<br>{<br>=A0 if (val &gt;=3D range.first &amp;&amp; val &lt; range.secon=
d) {<br>=A0=A0=A0 func();<br>=A0=A0=A0 return;<br>=A0 }<br>=A0 range_switch=
(val, rest...);<br>}<br><br>template &lt;class T, class U&gt; auto range_ca=
se(T&amp;&amp; t, U&amp;&amp;u) -&gt; decltype(std::make_pair(std::forward&=
lt;T&gt;(t), std::forward&lt;U&gt;(u))) {<br>
=A0 return std::make_pair(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u=
));<br>}<br><br>#define rcase(a, b, c) range_case((a), (b)), []()c<br>int m=
ain()<br>{<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 rcase(1,3=
, {<br>=A0=A0=A0 =A0=A0 =A0=A0=A0 std::cout &lt;&lt; &quot;[1,3)&quot; &lt;=
&lt; std::endl;<br>
=A0=A0=A0 =A0=A0=A0=A0=A0=A0 }),<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 rcase(4,7,=
 { <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 std::cout &lt;&lt; &quot;[4=
,7)&quot; &lt;&lt; std::endl;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 }));<br>=A0=A0=A0 =A0 =A0<br>}<br><br><br></div><div>Initializer-list vers=
ion:<br><br>#include &lt;iostream&gt;<br>
#include &lt;utility&gt;<br>#include &lt;tuple&gt;<br>#include &lt;initiali=
zer_list&gt;<br>#include &lt;functional&gt;<br><br><br>void range_switch(in=
t val, std::initializer_list&lt;std::tuple&lt;int, int, std::function&lt;vo=
id()&gt;&gt;&gt; cases)<br>
{<br>=A0 for (const auto&amp; i : cases) {<br>=A0=A0=A0 if (val &gt;=3D std=
::get&lt;0&gt;(i) &amp;&amp; val &lt; std::get&lt;1&gt;(i)) {<br>=A0=A0=A0=
=A0=A0 std::get&lt;2&gt;(i)();<br>=A0=A0=A0=A0=A0 break;<br>=A0=A0=A0 }<br>=
=A0 }<br>}<br><br>template &lt;class... Args&gt; auto range_case(Args&amp;&=
amp;... args)<br>
=A0 -&gt; decltype(std::make_tuple(std::forward&lt;Args&gt;(args)...)) {<br=
>=A0 return std::make_tuple(std::forward&lt;Args&gt;(args)...);<br>}<br><br=
>int main()<br>{<br>=A0 range_switch(6, {<br>=A0=A0=A0=A0=A0 range_case(1,3=
, <br>=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1,3)&quot;=
 &lt;&lt; std::endl;}),<br>
=A0=A0=A0=A0=A0 range_case(4,7, <br>=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::c=
out &lt;&lt; &quot;[4,7)&quot; &lt;&lt; std::endl;})<br>=A0 });<br>}<br><br=
></div></div><br></div></div>

<p></p>

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

--047d7bdc9396d6d32104e254acb7--

.

--089e011826104e3c7a04e25509a8
Content-Type: text/plain; charset=ISO-8859-1

A reason to use switch cases is to be able to not 'break' and fall through
to the next case. This feature is not available in the example solutions
given before in this thread, but it is possible: Here's an example that
shows that it is possible: https://gist.github.com/m-ou-se/6079075  It
combines Ville's lambda-eating range_switch variadic function template with
some macro hackery.

--

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



--089e011826104e3c7a04e25509a8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

A reason to use switch cases is to be able to not 'break' and fall =
through to the next case. This feature is not available in the example solu=
tions given before in this thread, but it is possible: Here's an exampl=
e that shows that it is possible: <a href=3D"https://gist.github.com/m-ou-s=
e/6079075">https://gist.github.com/m-ou-se/6079075</a>=A0 It combines Ville=
&#39;s lambda-eating range_switch variadic function template with some macr=
o hackery.<br>

<p></p>

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

--089e011826104e3c7a04e25509a8--

.

--001a11330f14eecbb704e27a959f
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 25, 2013 at 11:18 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 25 July 2013 12:21, Laszlo Papp <lpapp@kde.org> wrote:
>
>>
>>
>>
>>>  I'm still waiting for someone to elaborate why this feature proposal
>>> would be worth its costs.
>>>
>>
>> It results a more readable code than this:
>>
>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
>> case 9: do_something(); break;
>>
>
> Yeah, then I guess I'm still waiting, since you could just write that with
> a single if and get much more readable
> code.
>

You could always write if when you use switches, but we would not like to
abandon it, regardless. The fact that switch exists shows that it provides
some advantage over if. It is simply just a better structure in certain
cases, but I do not think it needs explanation.


>
> Do people consider this readable?
>
>   range_switch(6,
>            range_case(1,3),
>                [](){std::cout << "[1,3)" << std::endl;},
>            range_case(4,7),
>                [](){std::cout << "[4,7)" << std::endl;})
>

I personally do not prefer it.


>
>> But yes, there are other problems with the switch statement in C++.
>> Perhaps, we should introduce a new structure where "case" and "break" are
>> unnecessary, and it could support ranges, merges for several, but
>> non-continuous values?
>>
>>
>>
> Perhaps we can already write such structures without core language changes.
>

This proposal is trying to extend an already existing core language
structure to be more powerful. In my opinion, it is better to have a
powerful "self-contained" structure rather than a half-baked with some
extension outside the language.

Laszlo

--

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



--001a11330f14eecbb704e27a959f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Jul 25, 2013 at 11:18 AM, Ville Voutilainen <span =
dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_b=
lank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gm=
ail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div clas=
s=3D"im">On 25 July 2013 12:21, Laszlo Papp <span dir=3D"ltr">&lt;<a href=
=3D"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><br>=A0<div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div>I&#39;m still waiting for someone to elaborate why this feature propos=
al would be worth its costs.=A0<br></div></div></div></div></blockquote><di=
v><br></div></div><div>It results a more readable code than this:</div><div=
>

<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>

</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br></div></div></div></div></blockquote><div><br>
</div><div>You could always write if when you use switches, but we would no=
t like to abandon it, regardless. The fact that switch exists shows that it=
 provides some advantage over if. It is simply just a better structure in c=
ertain cases, but I do not think it needs explanation.</div>
<div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>Do people =
consider this readable?<br>

<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(1,3), <b=
r>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1=
,3)&quot; &lt;&lt; std::endl;},<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(=
4,7), <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; =
&quot;[4,7)&quot; &lt;&lt; std::endl;})<br>
</div></div></div></div></blockquote><div><br></div><div>I personally do no=
t prefer it.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><div class=
=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra">
<div class=3D"gmail_quote"><div><div>
<br></div></div><div>
But yes, there are other problems with the switch statement in C++. Perhaps=
, we should introduce a new structure where &quot;case&quot; and &quot;brea=
k&quot; are unnecessary, and it could support ranges, merges for several, b=
ut non-continuous values?</div>

<span><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div></div><div>Perhaps we can already write such structures without core la=
nguage changes.<br></div></div></div></div></blockquote><div><br></div>
<div>This proposal is trying to extend an already existing core language st=
ructure to be more powerful. In my opinion, it is better to have a powerful=
 &quot;self-contained&quot; structure rather than a half-baked with some ex=
tension outside the language.</div>
<div><br></div><div>Laszlo</div></div></div></div>

<p></p>

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

--001a11330f14eecbb704e27a959f--

.

--089e013cbae84c43d604e27cedab
Content-Type: text/plain; charset=ISO-8859-1

On 27 July 2013 12:07, Laszlo Papp <lpapp@kde.org> wrote:

> It results a more readable code than this:
>
>>
>>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
>>> case 9: do_something(); break;
>>>
>>
>> Yeah, then I guess I'm still waiting, since you could just write that
>> with a single if and get much more readable
>> code.
>>
>
> You could always write if when you use switches, but we would not like to
> abandon it, regardless. The fact that switch exists shows that it provides
> some advantage over if. It is simply just a better structure in certain
> cases, but I do not think it needs explanation.
>

Then we need more convincing rationale than code like above.


>
>
>>
>> Do people consider this readable?
>>
>>   range_switch(6,
>>            range_case(1,3),
>>                [](){std::cout << "[1,3)" << std::endl;},
>>            range_case(4,7),
>>                [](){std::cout << "[4,7)" << std::endl;})
>>
>
> I personally do not prefer it.
>

Why? As Olaf pointed out, it's very close to what we can achieve with the
gcc range-case extension.
And Maurice showed how to add break support to it.



>
>
>
>> Perhaps we can already write such structures without core language
>> changes.
>>
>
> This proposal is trying to extend an already existing core language
> structure to be more powerful. In my opinion, it is better to have a
> powerful "self-contained" structure rather than a half-baked with some
> extension outside the language.
>
>
>
At any rate, a language extension proposal needs to consider the
alternatives and also the necessity
of a language extension. The advantages of adding a library extension
usually outweigh the alleged
"half-baked" nature of non-core extensions.

--

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



--089e013cbae84c43d604e27cedab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 July 2013 12:07, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">It results a more readable code than this:<div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra">
<div class=3D"gmail_quote"><div>

<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>


</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br></div></div></div></div></blockquote><div><br>

</div></div><div>You could always write if when you use switches, but we wo=
uld not like to abandon it, regardless. The fact that switch exists shows t=
hat it provides some advantage over if. It is simply just a better structur=
e in certain cases, but I do not think it needs explanation.</div>
</div></div></div></blockquote><div><br></div><div>Then we need more convin=
cing rationale than code like above.<br>=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">
<div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>Do people =
consider this readable?<br>


<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(1,3), <b=
r>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1=
,3)&quot; &lt;&lt; std::endl;},<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(=
4,7), <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; =
&quot;[4,7)&quot; &lt;&lt; std::endl;})<br>

</div></div></div></div></blockquote><div><br></div></div><div>I personally=
 do not prefer it.</div></div></div></div></blockquote><div><br></div><div>=
Why? As Olaf pointed out, it&#39;s very close to what we can achieve with t=
he gcc range-case extension.<br>
</div><div>And Maurice showed how to add break support to it.<br><br>=A0<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra">
<div class=3D"gmail_quote"><div class=3D"im"><br><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span><font color=3D"#888888">=
<div><br></div></font></span></div></div></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div><br></div></div><div>Perhaps we can already write such structures wit=
hout core language changes.<br></div></div></div></div></blockquote><div><b=
r>
</div>
</div><div>This proposal is trying to extend an already existing core langu=
age structure to be more powerful. In my opinion, it is better to have a po=
werful &quot;self-contained&quot; structure rather than a half-baked with s=
ome extension outside the language.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div><div>At any rate, a language extension proposal needs to consider the a=
lternatives and also the necessity<br>of a language extension. The advantag=
es of adding a library extension usually outweigh the alleged<br>
</div><div>&quot;half-baked&quot; nature of non-core extensions.<br></div><=
/div><br></div></div>

<p></p>

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

--089e013cbae84c43d604e27cedab--

.

--047d7b0721ca52f34604e27d18c0
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 27, 2013 at 12:54 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 27 July 2013 12:07, Laszlo Papp <lpapp@kde.org> wrote:
>
>> It results a more readable code than this:
>>
>>>
>>>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8:
>>>> case 9: do_something(); break;
>>>>
>>>
>>> Yeah, then I guess I'm still waiting, since you could just write that
>>> with a single if and get much more readable
>>> code.
>>>
>>
>> You could always write if when you use switches, but we would not like to
>> abandon it, regardless. The fact that switch exists shows that it provides
>> some advantage over if. It is simply just a better structure in certain
>> cases, but I do not think it needs explanation.
>>
>
> Then we need more convincing rationale than code like above.
>

More convincing rationale than what situations it exactly solves?


>
>
>>
>>
>>>
>>> Do people consider this readable?
>>>
>>>   range_switch(6,
>>>            range_case(1,3),
>>>                [](){std::cout << "[1,3)" << std::endl;},
>>>            range_case(4,7),
>>>                [](){std::cout << "[4,7)" << std::endl;})
>>>
>>
>> I personally do not prefer it.
>>
>
> Why? As Olaf pointed out, it's very close to what we can achieve with the
> gcc range-case extension.
> And Maurice showed how to add break support to it.
>

Simply because I would need to use two types of switches now: a
"range_switch", and "switch". Why so much hassle when it can be
self-contained easy-peasily?


>
>>
>>
>>> Perhaps we can already write such structures without core language
>>> changes.
>>>
>>
>>  This proposal is trying to extend an already existing core language
>> structure to be more powerful. In my opinion, it is better to have a
>> powerful "self-contained" structure rather than a half-baked with some
>> extension outside the language.
>>
>>
>>
> At any rate, a language extension proposal needs to consider the
> alternatives and also the necessity
> of a language extension.
>

Sure, it has been considered, but I do not think it is pretty enough.

 The advantages of adding a library extension usually outweigh the alleged

> "half-baked" nature of non-core extensions.
>

No no, I mean "half-baked" nature of core language feature.

At any rate, outweigh in what sense? I do not see any benefit of not having
a "self-contained" core feature. What additional benefit would bring that
to us?

Laszlo

--

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



--047d7b0721ca52f34604e27d18c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Jul 27, 2013 at 12:54 PM, Ville Voutilainen <span =
dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_b=
lank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gm=
ail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div clas=
s=3D"im">On 27 July 2013 12:07, Laszlo Papp <span dir=3D"ltr">&lt;<a href=
=3D"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">It results a more readable code than this:<div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra">

<div class=3D"gmail_quote"><div>

<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>



</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br></div></div></div></div></blockquote><div><br>


</div></div><div>You could always write if when you use switches, but we wo=
uld not like to abandon it, regardless. The fact that switch exists shows t=
hat it provides some advantage over if. It is simply just a better structur=
e in certain cases, but I do not think it needs explanation.</div>

</div></div></div></blockquote><div><br></div></div><div>Then we need more =
convincing rationale than code like above.<br></div></div></div></div></blo=
ckquote><div><br></div><div>More convincing rationale than what situations =
it exactly solves?</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>=A0<br></div><div class=3D"im=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>
<div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>Do people =
consider this readable?<br>



<br>=A0 range_switch(6,<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(1,3), <b=
r>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; &quot;[1=
,3)&quot; &lt;&lt; std::endl;},<br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0 range_case(=
4,7), <br>=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [](){std::cout &lt;&lt; =
&quot;[4,7)&quot; &lt;&lt; std::endl;})<br>


</div></div></div></div></blockquote><div><br></div></div><div>I personally=
 do not prefer it.</div></div></div></div></blockquote><div><br></div></div=
><div>Why? As Olaf pointed out, it&#39;s very close to what we can achieve =
with the gcc range-case extension.<br>

</div><div>And Maurice showed how to add break support to it.<br></div></di=
v></div></div></blockquote><div><br></div><div>Simply because I would need =
to use two types of switches now: a &quot;range_switch&quot;, and &quot;swi=
tch&quot;. Why so much hassle when it can be self-contained easy-peasily?</=
div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><span><font color=3D"#888888"><div><br></div></font></span></div></div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div><br></div></div><div>Perhaps we can already write such structures wit=
hout core language changes.<br></div></div></div></div></blockquote><div><b=
r>

</div>
</div><div>This proposal is trying to extend an already existing core langu=
age structure to be more powerful. In my opinion, it is better to have a po=
werful &quot;self-contained&quot; structure rather than a half-baked with s=
ome extension outside the language.</div>

<span><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div></div><div>At any rate, a language extension proposal needs to consider=
 the alternatives and also the necessity<br>of a language extension.</div>
</div></div></div></blockquote><div><br></div><div>Sure, it has been consid=
ered, but I do not think it is pretty enough.</div><div><br></div><div>=A0T=
he advantages of adding a library extension usually outweigh the alleged</d=
iv>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>&quot;half-baked&quot; nature of non-core e=
xtensions.<br>
</div></div></div></div></blockquote><div><br></div><div>No no, I mean &quo=
t;half-baked&quot; nature of core language feature.</div><div><br></div><di=
v>At any rate, outweigh in what sense? I do not see any benefit of not havi=
ng a &quot;self-contained&quot; core feature. What additional benefit would=
 bring that to us?</div>
<div><br></div><div>Laszlo</div></div></div></div>

<p></p>

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

--047d7b0721ca52f34604e27d18c0--

.

--001a11c339e8f90edc04e27d2c33
Content-Type: text/plain; charset=ISO-8859-1

On 27 July 2013 15:06, Laszlo Papp <lpapp@kde.org> wrote:

> On 27 July 2013 12:07, Laszlo Papp <lpapp@kde.org> wrote:
>
>> It results a more readable code than this:
>>>
>>>>
>>>>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case
>>>>> 8: case 9: do_something(); break;
>>>>>
>>>>
>>>> Yeah, then I guess I'm still waiting, since you could just write that
>>>> with a single if and get much more readable
>>>> code.
>>>>
>>>
>>> You could always write if when you use switches, but we would not like
>>> to abandon it, regardless. The fact that switch exists shows that it
>>> provides some advantage over if. It is simply just a better structure in
>>> certain cases, but I do not think it needs explanation.
>>>
>>
>> Then we need more convincing rationale than code like above.
>>
>
> More convincing rationale than what situations it exactly solves?
>

More convincing rationale than an example that's unreadable with a switch
compared to an if.


Simply because I would need to use two types of switches now: a
> "range_switch", and "switch". Why so much hassle when it can be
> self-contained easy-peasily?
>

Easy-peasily? Changing the standard and all the implementations is
easy-peasy? That's news to me.
The library solution can be adopted without having to do either of those,
and if user experience
shows that it's desirable enough, adopting it into the standard is much
easier than adopting
a core change.


>
>
>> At any rate, a language extension proposal needs to consider the
>> alternatives and also the necessity
>> of a language extension.
>>
>
> Sure, it has been considered, but I do not think it is pretty enough.
>

Considered? There's no written proposal, so I can't fathom what that
theoretical proposal does or does
not consider. Such considerations should be in the proposal paper, not in
people's heads.



>
>  The advantages of adding a library extension usually outweigh the alleged
>
>> "half-baked" nature of non-core extensions.
>>
>
> No no, I mean "half-baked" nature of core language feature.
>
> At any rate, outweigh in what sense? I do not see any benefit of not
> having a "self-contained" core feature. What additional benefit would bring
> that to us?
>
>
>
As explained earlier in this mail.

--

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



--001a11c339e8f90edc04e27d2c33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 July 2013 15:06, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On 27 July 2013 12:07, Laszlo Papp <span dir=3D"ltr">&lt;<=
a href=3D"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</sp=
an> wrote:<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">It results a more readable code than this:<div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra">


<div class=3D"gmail_quote"><div>

<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>




</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br></div></div></div></div></blockquote><div><br>



</div></div><div>You could always write if when you use switches, but we wo=
uld not like to abandon it, regardless. The fact that switch exists shows t=
hat it provides some advantage over if. It is simply just a better structur=
e in certain cases, but I do not think it needs explanation.</div>


</div></div></div></blockquote><div><br></div></div><div>Then we need more =
convincing rationale than code like above.<br></div></div></div></div></blo=
ckquote><div><br></div></div><div>More convincing rationale than what situa=
tions it exactly solves?</div>
</div></div></div></blockquote><div><br></div><div>More convincing rational=
e than an example that&#39;s unreadable with a switch compared to an if.<br=
>=A0<br> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><div></div></div><div>Simply because I would need to use two =
types of switches now: a &quot;range_switch&quot;, and &quot;switch&quot;. =
Why so much hassle when it can be self-contained easy-peasily?</div>
</div></div></div></blockquote><div><br></div><div>Easy-peasily? Changing t=
he standard and all the implementations is easy-peasy? That&#39;s news to m=
e.<br></div><div>The library solution can be adopted without having to do e=
ither of those, and if user experience<br>
shows that it&#39;s desirable enough, adopting it into the standard is much=
 easier than adopting<br>a core change.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><br><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><span><font color=3D"#888888"><div><br></div></font></span></=
div></div></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div><div><br></div></div><div>At any rate, a la=
nguage extension proposal needs to consider the alternatives and also the n=
ecessity<br>
of a language extension.</div>
</div></div></div></blockquote><div><br></div></div><div>Sure, it has been =
considered, but I do not think it is pretty enough.</div></div></div></div>=
</blockquote><div><br></div><div>Considered? There&#39;s no written proposa=
l, so I can&#39;t fathom what that theoretical proposal does or does<br>
not consider. Such considerations should be in the proposal paper, not in p=
eople&#39;s heads.<br><br>=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><di=
v><br></div><div>=A0The advantages of adding a library extension usually ou=
tweigh the alleged</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>&quot;half-baked&quot; nature of non-core e=
xtensions.<br>

</div></div></div></div></blockquote><div><br></div></div><div>No no, I mea=
n &quot;half-baked&quot; nature of core language feature.</div><div><br></d=
iv><div>At any rate, outweigh in what sense? I do not see any benefit of no=
t having a &quot;self-contained&quot; core feature. What additional benefit=
 would bring that to us?</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div><div>As explained earlier in this mail. <br></div></div><br></div></div=
>

<p></p>

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

--001a11c339e8f90edc04e27d2c33--

.

--047d7b6d908a347eb804e27e1199
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 27, 2013 at 1:12 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 27 July 2013 15:06, Laszlo Papp <lpapp@kde.org> wrote:
>
>> On 27 July 2013 12:07, Laszlo Papp <lpapp@kde.org> wrote:
>>
>>>  It results a more readable code than this:
>>>>
>>>>>
>>>>>> case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case
>>>>>> 8: case 9: do_something(); break;
>>>>>>
>>>>>
>>>>> Yeah, then I guess I'm still waiting, since you could just write that
>>>>> with a single if and get much more readable
>>>>> code.
>>>>>
>>>>
>>>> You could always write if when you use switches, but we would not like
>>>> to abandon it, regardless. The fact that switch exists shows that it
>>>> provides some advantage over if. It is simply just a better structure in
>>>> certain cases, but I do not think it needs explanation.
>>>>
>>>
>>> Then we need more convincing rationale than code like above.
>>>
>>
>> More convincing rationale than what situations it exactly solves?
>>
>
> More convincing rationale than an example that's unreadable with a switch
> compared to an if.
>

As I wrote before, I am not discussing "if" in here, but improving
"switch". You know... when you do not need to repeat the "else if (foo ==
i)" parts, but using cases.


>  Simply because I would need to use two types of switches now: a
> "range_switch", and "switch". Why so much hassle when it can be
> self-contained easy-peasily?
>
> Easy-peasily? Changing the standard and all the implementations is
> easy-peasy? That's news to me.
>

Well, for also got range support instead of leaving the libraries
implementing the "foreach" syntax.


> The library solution can be adopted without having to do either of those,
> and if user experience
> shows that it's desirable enough, adopting it into the standard is much
> easier than adopting
> a core change.
>

Well, my and others' user experience have shown that it is useful. The gcc
people have been added it long ago, so did many other languages. I am not
claiming every language is perfect, but it is still somewhat an indication.

Not to mention, it is very unlikely someone will support an additional
dependency just because of this even though they would like to have this
feature. It will be less hassle to use "if" or any other workaround. That
does not mean they would not use this feature if it was in the language
itself.


> At any rate, a language extension proposal needs to consider the
>>> alternatives and also the necessity
>>> of a language extension.
>>>
>>
>> Sure, it has been considered, but I do not think it is pretty enough.
>>
>
> Considered? There's no written proposal, so I can't fathom what that
> theoretical proposal does or does
> not consider. Such considerations should be in the proposal paper, not in
> people's heads.
>

Yes, in this thread. It has been discussed, but I expressed why I do not
like it.


>  The advantages of adding a library extension usually outweigh the alleged
>>
>>> "half-baked" nature of non-core extensions.
>>>
>>
>> No no, I mean "half-baked" nature of core language feature.
>>
>> At any rate, outweigh in what sense? I do not see any benefit of not
>> having a "self-contained" core feature. What additional benefit would bring
>> that to us?
>>
>>
>>
> As explained earlier in this mail.
>

OK, it has not convinced me.

Laszlo

--

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



--047d7b6d908a347eb804e27e1199
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Jul 27, 2013 at 1:12 PM, Ville Voutilainen <span dir=3D"ltr=
">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vill=
e.voutilainen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 27 July 2013 15=
:06, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D"mailto:lpapp@kde.org" tar=
get=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On 27 July 2013 12:07, Laszlo Papp <span dir=3D"ltr">&lt;<=
a href=3D"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</sp=
an> wrote:<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">

<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">It results a more readable code than this:<div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra">



<div class=3D"gmail_quote"><div>

<div><br>
</div><div><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;f=
ont-size:13px">case 0: case 1: case 2: case 3: case 4: case 5: case 6: case=
 7: case 8: case 9: do_something(); break;</span></div></div></div></div>





</div></blockquote><div><br></div></div><div>Yeah, then I guess I&#39;m sti=
ll waiting, since you could just write that with a single if and get much m=
ore readable<br>code.<br></div></div></div></div></blockquote><div><br>




</div></div><div>You could always write if when you use switches, but we wo=
uld not like to abandon it, regardless. The fact that switch exists shows t=
hat it provides some advantage over if. It is simply just a better structur=
e in certain cases, but I do not think it needs explanation.</div>



</div></div></div></blockquote><div><br></div></div><div>Then we need more =
convincing rationale than code like above.<br></div></div></div></div></blo=
ckquote><div><br></div></div><div>More convincing rationale than what situa=
tions it exactly solves?</div>

</div></div></div></blockquote><div><br></div></div><div>More convincing ra=
tionale than an example that&#39;s unreadable with a switch compared to an =
if.<br></div></div></div></div></blockquote><div><br></div><div>As I wrote =
before, I am not discussing &quot;if&quot; in here, but improving &quot;swi=
tch&quot;. You know... when you do not need to repeat the &quot;else if (fo=
o =3D=3D i)&quot; parts, but using cases.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div>=A0<span style=3D"color:rgb(8=
0,0,80)">Simply because I would need to use two types of switches now: a &q=
uot;range_switch&quot;, and &quot;switch&quot;. Why so much hassle when it =
can be self-contained easy-peasily?</span></div>
<div class=3D"im"><div><br></div></div><div>Easy-peasily? Changing the stan=
dard and all the implementations is easy-peasy? That&#39;s news to me.<br><=
/div></div></div></div></blockquote><div><br></div><div>Well, for also got =
range support instead of leaving the libraries implementing the &quot;forea=
ch&quot; syntax.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div></div><div>The library soluti=
on can be adopted without having to do either of those, and if user experie=
nce<br>

shows that it&#39;s desirable enough, adopting it into the standard is much=
 easier than adopting<br>a core change.<br></div></div></div></div></blockq=
uote><div><br></div><div>Well, my and others&#39; user experience have show=
n that it is useful. The gcc people have been added it long ago, so did man=
y other languages. I am not claiming every language is perfect, but it is s=
till somewhat an indication.</div>
<div><br></div><div>Not to mention, it is very unlikely someone will suppor=
t an additional dependency just because of this even though they would like=
 to have this feature. It will be less hassle to use &quot;if&quot; or any =
other workaround. That does not mean they would not use this feature if it =
was in the language itself.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote">
<div><div>At any rate, a language extension proposal needs to consider the =
alternatives and also the necessity<br></div></div><div>
of a language extension.</div>
</div></div></div></blockquote><div><br></div></div><div>Sure, it has been =
considered, but I do not think it is pretty enough.</div></div></div></div>=
</blockquote><div><br></div></div><div>Considered? There&#39;s no written p=
roposal, so I can&#39;t fathom what that theoretical proposal does or does<=
br>

not consider. Such considerations should be in the proposal paper, not in p=
eople&#39;s heads.<br></div></div></div></div></blockquote><div><br></div><=
div>Yes, in this thread. It has been discussed, but I expressed why I do no=
t like it.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><div>=A0The advantages of adding a library extension usually outweigh the =
alleged<br></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>&quot;half-baked&quot; nature of non-core e=
xtensions.<br>


</div></div></div></div></blockquote><div><br></div></div><div>No no, I mea=
n &quot;half-baked&quot; nature of core language feature.</div><div><br></d=
iv><div>At any rate, outweigh in what sense? I do not see any benefit of no=
t having a &quot;self-contained&quot; core feature. What additional benefit=
 would bring that to us?</div>

<span><font color=3D"#888888">
<div><br><br></div></font></span></div></div></div></blockquote><div><br></=
div></div><div>As explained earlier in this mail. <br></div></div></div></d=
iv></blockquote><div><br></div><div>OK, it has not convinced me.</div>
<div><br></div><div>Laszlo</div></div></div></div>

<p></p>

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

--047d7b6d908a347eb804e27e1199--

.

--089e013cbae8fad60104e2800d93
Content-Type: text/plain; charset=ISO-8859-1

On 27 July 2013 16:16, Laszlo Papp <lpapp@kde.org> wrote:

>
> More convincing rationale than an example that's unreadable with a switch
>> compared to an if.
>>
>
> As I wrote before, I am not discussing "if" in here, but improving
> "switch". You know... when you do not need to repeat the "else if (foo ==
> i)" parts, but using cases.
>

Well, for a proposal it would be a good idea to have an actual example of
what exactly it's targeting to
improve, rather than something unrelated.


>
> Easy-peasily? Changing the standard and all the implementations is
>> easy-peasy? That's news to me.
>>
>
> Well, for also got range support instead of leaving the libraries
> implementing the "foreach" syntax.
>

There's one major difference between a range-for and a range-case;
range-for is incredibly
common.


>
>
>> The library solution can be adopted without having to do either of those,
>> and if user experience
>> shows that it's desirable enough, adopting it into the standard is much
>> easier than adopting
>> a core change.
>>
>
> Well, my and others' user experience have shown that it is useful. The gcc
> people have been added it long ago, so did many other languages. I am not
> claiming every language is perfect, but it is still somewhat an indication.
>

The question is whether it's useful enough to be worth standardizing, and
whether it's superior to alternatives.
That's also something a proposal should discuss.


>
> Not to mention, it is very unlikely someone will support an additional
> dependency just because of this even though they would like to have this
> feature. It will be less hassle to use "if" or any other workaround. That
> does not mean they would not use this feature if it was in the language
> itself.
>

The additional dependency vanishes the moment a library solution is
standardized, but before standardization,
it allows experimentation without having to modify compilers. At any rate,
we're looking at a header-only
utility here.



>
>
>>  At any rate, a language extension proposal needs to consider the
>>>> alternatives and also the necessity
>>>> of a language extension.
>>>>
>>>
>>> Sure, it has been considered, but I do not think it is pretty enough.
>>>
>>
>> Considered? There's no written proposal, so I can't fathom what that
>> theoretical proposal does or does
>> not consider. Such considerations should be in the proposal paper, not in
>> people's heads.
>>
>
> Yes, in this thread. It has been discussed, but I expressed why I do not
> like it.
>

Not being pretty enough? I guess that's in the eye of a beholder,
especially when there are breaks
involved in the cases.

--

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



--089e013cbae8fad60104e2800d93
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 July 2013 16:16, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra">
<div class=3D"gmail_quote"><div>More convincing rationale than an example t=
hat&#39;s unreadable with a switch compared to an if.<br></div></div></div>=
</div></blockquote><div><br></div></div><div>As I wrote before, I am not di=
scussing &quot;if&quot; in here, but improving &quot;switch&quot;. You know=
.... when you do not need to repeat the &quot;else if (foo =3D=3D i)&quot; p=
arts, but using cases.</div>
</div></div></div></blockquote><div><br></div><div>Well, for a proposal it =
would be a good idea to have an actual example of what exactly it&#39;s tar=
geting to<br>improve, rather than something unrelated.<br>=A0<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra">
<div class=3D"gmail_quote"><div>Easy-peasily? Changing the standard and all=
 the implementations is easy-peasy? That&#39;s news to me.<br></div></div><=
/div></div></blockquote><div><br></div></div><div>Well, for also got range =
support instead of leaving the libraries implementing the &quot;foreach&quo=
t; syntax.</div>
</div></div></div></blockquote><div><br></div><div>There&#39;s one major di=
fference between a range-for and a range-case; range-for is incredibly<br><=
/div><div>common.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im">
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div></div><div>The library soluti=
on can be adopted without having to do either of those, and if user experie=
nce<br>


shows that it&#39;s desirable enough, adopting it into the standard is much=
 easier than adopting<br>a core change.<br></div></div></div></div></blockq=
uote><div><br></div></div><div>Well, my and others&#39; user experience hav=
e shown that it is useful. The gcc people have been added it long ago, so d=
id many other languages. I am not claiming every language is perfect, but i=
t is still somewhat an indication.</div>
</div></div></div></blockquote><div><br></div><div>The question is whether =
it&#39;s useful enough to be worth standardizing, and whether it&#39;s supe=
rior to alternatives.<br></div><div>That&#39;s also something a proposal sh=
ould discuss.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote">
<div><br></div><div>Not to mention, it is very unlikely someone will suppor=
t an additional dependency just because of this even though they would like=
 to have this feature. It will be less hassle to use &quot;if&quot; or any =
other workaround. That does not mean they would not use this feature if it =
was in the language itself.</div>
</div></div></div></blockquote><div><br></div><div>The additional dependenc=
y vanishes the moment a library solution is standardized, but before standa=
rdization,<br>it allows experimentation without having to modify compilers.=
 At any rate, we&#39;re looking at a header-only<br>
</div><div>utility here.<br></div><div><br>=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<div class=3D"im">
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote">

<div><div>At any rate, a language extension proposal needs to consider the =
alternatives and also the necessity<br></div></div><div>
of a language extension.</div>
</div></div></div></blockquote><div><br></div></div><div>Sure, it has been =
considered, but I do not think it is pretty enough.</div></div></div></div>=
</blockquote><div><br></div></div><div>Considered? There&#39;s no written p=
roposal, so I can&#39;t fathom what that theoretical proposal does or does<=
br>


not consider. Such considerations should be in the proposal paper, not in p=
eople&#39;s heads.<br></div></div></div></div></blockquote><div><br></div><=
/div><div>Yes, in this thread. It has been discussed, but I expressed why I=
 do not like it.</div>
</div></div></div></blockquote><div><br></div><div>Not being pretty enough?=
 I guess that&#39;s in the eye of a beholder, especially when there are bre=
aks<br>involved in the cases.<br><br></div></div><br></div></div>

<p></p>

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

--089e013cbae8fad60104e2800d93--

.

--047d7b0721cacb106604e28045ac
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 27, 2013 at 4:38 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 27 July 2013 16:16, Laszlo Papp <lpapp@kde.org> wrote:
>
>>
>> More convincing rationale than an example that's unreadable with a switch
>>> compared to an if.
>>>
>>
>> As I wrote before, I am not discussing "if" in here, but improving
>> "switch". You know... when you do not need to repeat the "else if (foo ==
>> i)" parts, but using cases.
>>
>
> Well, for a proposal it would be a good idea to have an actual example of
> what exactly it's targeting to
> improve, rather than something unrelated.
>

It has been presented.


>
>
>> Easy-peasily? Changing the standard and all the implementations is
>>> easy-peasy? That's news to me.
>>>
>>
>> Well, for also got range support instead of leaving the libraries
>> implementing the "foreach" syntax.
>>
>
> There's one major difference between a range-for and a range-case;
> range-for is incredibly
> common.
>

I am not talking about commonality. It was a reply to "easy-peasy". It is
just the same process. Commonality is a different metrics. Perhaps "final"
and some other features are just as less used as case ranges compared to
"foreach"?

That does not mean that they are excluded because they are somewhat less
common. I have never claimed it is the most wanted feature ever, and could
not claim so.


> Not to mention, it is very unlikely someone will support an additional
>> dependency just because of this even though they would like to have this
>> feature. It will be less hassle to use "if" or any other workaround. That
>> does not mean they would not use this feature if it was in the language
>> itself.
>>
>
> The additional dependency vanishes the moment a library solution is
> standardized, but before standardization,
> it allows experimentation without having to modify compilers. At any rate,
> we're looking at a header-only
> utility here.
>

The problem is that not many people will bother, including me, if it is not
available in the language. It is not accidental that the gcc people had
these extensions alongside other languages. How many people bothered to
have an "override" processor even if it is now common that it is in the new
standard.

Anyway, I do not think it needs to be discussed more. Let us not have such
a feature standardized then if people think it is a very rare case to use
ranges.

Laszlo

--

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



--047d7b0721cacb106604e28045ac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Jul 27, 2013 at 4:38 PM, Ville Voutilainen <span dir=3D"ltr=
">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">vill=
e.voutilainen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"color:rgb(80=
,0,80)">On 27 July 2013 16:16, Laszlo Papp </span><span dir=3D"ltr" style=
=3D"color:rgb(80,0,80)">&lt;<a href=3D"mailto:lpapp@kde.org" target=3D"_bla=
nk">lpapp@kde.org</a>&gt;</span><span style=3D"color:rgb(80,0,80)"> wrote:<=
/span><br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra">
<div class=3D"gmail_quote"><div>More convincing rationale than an example t=
hat&#39;s unreadable with a switch compared to an if.<br></div></div></div>=
</div></blockquote><div><br></div></div><div>As I wrote before, I am not di=
scussing &quot;if&quot; in here, but improving &quot;switch&quot;. You know=
.... when you do not need to repeat the &quot;else if (foo =3D=3D i)&quot; p=
arts, but using cases.</div>

</div></div></div></blockquote><div><br></div></div><div>Well, for a propos=
al it would be a good idea to have an actual example of what exactly it&#39=
;s targeting to<br>improve, rather than something unrelated.<br></div>
</div></div></div></blockquote><div><br></div><div>It has been presented.</=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra">
<div class=3D"gmail_quote"><div>=A0</div><div class=3D"im"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">
<div class=3D"gmail_quote"><div>Easy-peasily? Changing the standard and all=
 the implementations is easy-peasy? That&#39;s news to me.<br></div></div><=
/div></div></blockquote><div><br></div></div><div>Well, for also got range =
support instead of leaving the libraries implementing the &quot;foreach&quo=
t; syntax.</div>

</div></div></div></blockquote><div><br></div></div><div>There&#39;s one ma=
jor difference between a range-for and a range-case; range-for is incredibl=
y<br></div><div>common.<br></div></div></div></div></blockquote><div><br>
</div><div>I am not talking about commonality. It was a reply to &quot;easy=
-peasy&quot;. It is just the same process. Commonality is a different metri=
cs. Perhaps &quot;final&quot; and some other features are just as less used=
 as case ranges compared to &quot;foreach&quot;?</div>
<div><br></div><div>That does not mean that they are excluded because they =
are somewhat less common. I have never claimed it is the most wanted featur=
e ever, and could not claim so.</div><div>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_extra">
<div class=3D"gmail_quote"><div>Not to mention, it is very unlikely someone=
 will support an additional dependency just because of this even though the=
y would like to have this feature. It will be less hassle to use &quot;if&q=
uot; or any other workaround. That does not mean they would not use this fe=
ature if it was in the language itself.<br>
</div>
</div></div></div></blockquote><div><br></div></div><div>The additional dep=
endency vanishes the moment a library solution is standardized, but before =
standardization,<br>it allows experimentation without having to modify comp=
ilers. At any rate, we&#39;re looking at a header-only<br>

</div><div>utility here.<br></div></div></div></div></blockquote><div><br><=
/div><div>The problem is that not many people will bother, including me, if=
 it is not available in the language. It is not accidental that the gcc peo=
ple had these extensions alongside other languages. How many people bothere=
d to have an &quot;override&quot; processor even if it is now common that i=
t is in the new standard.</div>
<div><br></div><div>Anyway, I do not think it needs to be discussed more. L=
et us not have such a feature standardized then if people think it is a ver=
y rare case to use ranges.</div><div><br></div><div>Laszlo</div></div></div=
>
</div>

<p></p>

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

--047d7b0721cacb106604e28045ac--

.

--047d7b677f581838a604e281d89a
Content-Type: text/plain; charset=ISO-8859-1

On 27 July 2013 18:54, Laszlo Papp <lpapp@kde.org> wrote:

>
> Anyway, I do not think it needs to be discussed more. Let us not have such
> a feature standardized then if people think it is a very rare case to use
> ranges.
>
>
>
For other people's reference, if you give up this easily when people ask
questions, none of your wishes
will be standardized. This discussion is still far away from an actual
standards proposal, without which
nothing will happen.

--

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



--047d7b677f581838a604e281d89a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 July 2013 18:54, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div>Anyway, I do not think it needs to be discussed more. Let us not have =
such a feature standardized then if people think it is a very rare case to =
use ranges.</div>
<span class=3D"HOEnZb"><font color=3D"#888888"><div><br><br></div></font></=
span></div></div></div></blockquote><div><br></div><div>For other people&#3=
9;s reference, if you give up this easily when people ask questions, none o=
f your wishes<br>
will be standardized. This discussion is still far away from an actual stan=
dards proposal, without which<br></div><div>nothing will happen. <br></div>=
</div><br></div></div>

<p></p>

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

--047d7b677f581838a604e281d89a--

.

--bcaec530432914c37804e282614d
Content-Type: text/plain; charset=ISO-8859-1

For other people's reference, if most people object to the usefulness of
the feature in the thread, your wish will not be standardized. This
discussion is still far away from being supportive, without which nothing
will happen.


On Sat, Jul 27, 2013 at 6:46 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 27 July 2013 18:54, Laszlo Papp <lpapp@kde.org> wrote:
>
>>
>> Anyway, I do not think it needs to be discussed more. Let us not have
>> such a feature standardized then if people think it is a very rare case to
>> use ranges.
>>
>>
>>
> For other people's reference, if you give up this easily when people ask
> questions, none of your wishes
> will be standardized. This discussion is still far away from an actual
> standards proposal, without which
> nothing will happen.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>

--

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



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

<div dir=3D"ltr">For other people&#39;s reference, if most people object to=
 the usefulness of the feature in the thread, your wish will not be standar=
dized. This discussion is still far away from being supportive, without whi=
ch nothing will happen.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jul 2=
7, 2013 at 6:46 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mail=
to:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 27 July 2013 18=
:54, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D"mailto:lpapp@kde.org" tar=
get=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div>Anyway, I do not think it needs to be discussed more. Let us not have =
such a feature standardized then if people think it is a very rare case to =
use ranges.</div>

<span><font color=3D"#888888"><div><br><br></div></font></span></div></div>=
</div></blockquote><div><br></div></div><div>For other people&#39;s referen=
ce, if you give up this easily when people ask questions, none of your wish=
es<br>

will be standardized. This discussion is still far away from an actual stan=
dards proposal, without which<br></div><div>nothing will happen. <br></div>=
</div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@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>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--bcaec530432914c37804e282614d--

.

--20cf306844d59aadc804e2827ca0
Content-Type: text/plain; charset=ISO-8859-1

On 27 July 2013 21:25, Laszlo Papp <lpapp@kde.org> wrote:

> For other people's reference, if most people object to the usefulness of
> the feature in the thread, your wish will not be standardized. This
> discussion is still far away from being supportive, without which nothing
> will happen.
>
>
>
This forum is not representative of the committee. Assuming that resistance
here means resistance in
the committee is a misguided assumption. If you want to try proposing
standardizing the gcc extension,
feel free to do so. If there's nobody writing a proposal and nobody to
champion it, it's going nowhere.

--

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



--20cf306844d59aadc804e2827ca0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 27 July 2013 21:25, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D=
"mailto:lpapp@kde.org" target=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">For other people&#39;s reference, if most people object to=
 the usefulness of the feature in the thread, your wish will not be standar=
dized. This discussion is still far away from being supportive, without whi=
ch nothing will happen.</div>

<div class=3D"gmail_extra"><br><br></div></blockquote><div><br></div><div>T=
his forum is not representative of the committee. Assuming that resistance =
here means resistance in<br>the committee is a misguided assumption. If you=
 want to try proposing standardizing the gcc extension,<br>
</div><div>feel free to do so. If there&#39;s nobody writing a proposal and=
 nobody to champion it, it&#39;s going nowhere. <br></div></div><br></div><=
/div>

<p></p>

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

--20cf306844d59aadc804e2827ca0--

.

--bcaec530432963b93204e2829bed
Content-Type: text/plain; charset=ISO-8859-1

I concluded from the people's feedback that this idea shall go to the trash
which means it is not worth my time.

Hopefully, I will have more fruitful FOSS things to work on. :-)


On Sat, Jul 27, 2013 at 7:32 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 27 July 2013 21:25, Laszlo Papp <lpapp@kde.org> wrote:
>
>> For other people's reference, if most people object to the usefulness of
>> the feature in the thread, your wish will not be standardized. This
>> discussion is still far away from being supportive, without which nothing
>> will happen.
>>
>>
>>
> This forum is not representative of the committee. Assuming that
> resistance here means resistance in
> the committee is a misguided assumption. If you want to try proposing
> standardizing the gcc extension,
> feel free to do so. If there's nobody writing a proposal and nobody to
> champion it, it's going nowhere.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>

--

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



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

<div dir=3D"ltr">I concluded from the people&#39;s feedback that this idea =
shall go to the trash which means it is not worth my time.<div><br></div><d=
iv>Hopefully, I will have more fruitful FOSS things to work on. :-)</div></=
div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Jul 2=
7, 2013 at 7:32 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mail=
to:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 27 July 2013 21=
:25, Laszlo Papp <span dir=3D"ltr">&lt;<a href=3D"mailto:lpapp@kde.org" tar=
get=3D"_blank">lpapp@kde.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">For other people&#39;s reference, if most people object to=
 the usefulness of the feature in the thread, your wish will not be standar=
dized. This discussion is still far away from being supportive, without whi=
ch nothing will happen.</div>


<div class=3D"gmail_extra"><br><br></div></blockquote><div><br></div></div>=
<div>This forum is not representative of the committee. Assuming that resis=
tance here means resistance in<br>the committee is a misguided assumption. =
If you want to try proposing standardizing the gcc extension,<br>

</div><div>feel free to do so. If there&#39;s nobody writing a proposal and=
 nobody to champion it, it&#39;s going nowhere. <br></div></div><br></div><=
/div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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%2Bunsubscribe@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>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--bcaec530432963b93204e2829bed--

.

------=_Part_2301_17982464.1375957089828
Content-Type: text/plain; charset=ISO-8859-1

Two things were mentioned earlier in this thread which don't seem have been
followed up further (in this thread) as more useful extensions.
One is allowing cases to be predicates rather than constant values and the
other is string cases.

Both of this versions occur frequently in dynamic languages such as python
and provide power and convenience.
I would like to turn the discussion around and ask why those features
should not be added to C++?

There are a few subtle differences between if constructs and switch
constructs.
As already mentioned the switch is equivalent to saying I want to do
something based on the value of one variable only.
This improves readability.

You can also view a switch as being a compiler hint that optimisation into
a jump table may be possible.

In the predicate case the compiler could view it as a hint that it could
optimise the predicates in cases where the expressions are not opaque
(which will probably be rare?).
If predicates were allowed the syntax for ranges could be something like
"case (x > 0 && x < 10):"
or better using some kind of range predicate e.g. "case(in_range(x,0,10)):"
[aside - I'm surprised I've not found something like 'in_range' make its
way into the standard, perhaps it has and I've just not noticed it]/

In the string case the compiler could optimise with numerous possible
string lookup functions.
This would go a long way to reducing or eliminating the use cases for
programs like lex and yacc.

Another important issue is whether switches should be conceptual treated as
executing in series or in parallel and whether it is possible/desirable for
more than one case apply (exclusive switch vs parallel switch).
In the case of predicates it is not possible in general to guarantee only
one case applies. You could generate a compiler error if any non constexpr
expressions were used only if you provide the compiler with an instruction
that the switch is intended to be exclusive.

It would be very powerful if you could somehow expose enough for
optimisations like the Rete algorithm to be possible.
C++ could then be used to write production systems more directly rather
than wrapping up higher level conditional constructs.

The situation where multiple cases apply (the parallel switch) potentially
permits all cases being executed in parallel rather than series.
Granted direct support for parallelism in C++ is a whole new feature set.

In the series case it is no different from a cascade of if's and elses
other than the use of a single variable again.

I do feel there is scope for more general purpose constructs which are
simple use, read and maintain.

I think the important properties are:
 Fixed properties:
   1) examines exactly one variable   (though I can imagine all sorts of
possibilities with collections along the lines of foreach)
 Variable properties:
   a) how many cases should apply
          mutually-exclusive, non-exclusive
   b) mode of execution
          series or parallel
   c) optimisable - e.g. require cases to be constexpr

Of these I think c) is the hardest to pin down. a) comes up a lot. I think
at least a variant that does away with breaks would be welcome.
b) needs a whole working group. Personally I'm in favour of the cilk
approach and I think that would work well with parallelised switch
statements.

--

---
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_2301_17982464.1375957089828
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Two things were mentioned earlier in this thread which don't seem have been=
 followed up further (in this thread) as more useful extensions.<br>One is =
allowing cases to be predicates rather than constant values and the other i=
s string cases.<br><br>Both of this versions occur frequently in dynamic la=
nguages such as python and provide power and convenience.<br>I would like t=
o turn the discussion around and ask why those features should not be added=
 to C++?<br><br>There are a few subtle differences between if constructs an=
d switch constructs.<br>As already mentioned the switch is equivalent to sa=
ying I want to do something based on the value of one variable only.<br>Thi=
s improves readability.<br><br>You can also view a switch as being a compil=
er hint that optimisation into a jump table may be possible.<br><br>In the =
predicate case the compiler could view it as a hint that it could optimise =
the predicates in cases where the expressions are not opaque<br>(which will=
 probably be rare?).<br>If predicates were allowed the syntax for ranges co=
uld be something like&nbsp;&nbsp;&nbsp; "case (x &gt; 0 &amp;&amp; x &lt; 1=
0):"<br>or better using some kind of range predicate e.g. "case(in_range(x,=
0,10)):"<br>[aside - I'm surprised I've not found something like 'in_range'=
 make its way into the standard, perhaps it has and I've just not noticed i=
t]/<br><br>In the string case the compiler could optimise with numerous pos=
sible string lookup functions.<br>This would go a long way to reducing or e=
liminating the use cases for programs like lex and yacc.<br><br>Another imp=
ortant issue is whether switches should be conceptual treated as executing =
in series or in parallel and whether it is possible/desirable for<br>more t=
han one case apply (exclusive switch vs parallel switch). <br>In the case o=
f predicates it is not possible in general to guarantee only one case appli=
es. You could generate a compiler error if any non constexpr expressions we=
re used only if you provide the compiler with an instruction that the switc=
h is intended to be exclusive.<br><br>It would be very powerful if you coul=
d somehow expose enough for optimisations like the Rete algorithm to be pos=
sible.<br>C++ could then be used to write production systems more directly =
rather than wrapping up higher level conditional constructs.<br><br>The sit=
uation where multiple cases apply (the parallel switch) potentially permits=
 all cases being executed in parallel rather than series.<br>Granted direct=
 support for parallelism in C++ is a whole new feature set.<br><br>In the s=
eries case it is no different from a cascade of if's and elses other than t=
he use of a single variable again.<br><br>I do feel there is scope for more=
 general purpose constructs which are simple use, read and maintain.<br><br=
>I think the important properties are:<br>&nbsp;Fixed properties:<br>&nbsp;=
&nbsp; 1) examines exactly one variable&nbsp;&nbsp; (though I can imagine a=
ll sorts of possibilities with collections along the lines of foreach)<br>&=
nbsp;Variable properties:<br>&nbsp;&nbsp; a) how many cases should apply<br=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mutually-exclusive,=
 non-exclusive<br>&nbsp;&nbsp; b) mode of execution<br>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; series or parallel<br>&nbsp;&nbsp; c) op=
timisable - e.g. require cases to be constexpr<br><br>Of these I think c) i=
s the hardest to pin down. a) comes up a lot. I think at least a variant th=
at does away with breaks would be welcome.<br>b) needs a whole working grou=
p. Personally I'm in favour of the cilk approach and I think that would wor=
k well with parallelised switch statements.<br>

<p></p>

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

------=_Part_2301_17982464.1375957089828--

.

On Thu, Aug 8, 2013 at 6:18 AM,  <tortoise741@gmail.com> wrote:
> I think the important properties are:
>  Fixed properties:
>    1) examines exactly one variable   (though I can imagine all sorts of
> possibilities with collections along the lines of foreach)
>  Variable properties:
>    a) how many cases should apply
>           mutually-exclusive, non-exclusive
>    b) mode of execution
>           series or parallel
>    c) optimisable - e.g. require cases to be constexpr
>
> Of these I think c) is the hardest to pin down. a) comes up a lot. I think
> at least a variant that does away with breaks would be welcome.
> b) needs a whole working group. Personally I'm in favour of the cilk
> approach and I think that would work well with parallelised switch
> statements.

Just FYI, here is a proposal addressed c)

  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html

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

--

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



.