Topic: Dynamic return types
Author: r.p.nicholl@gmail.com
Date: Tue, 12 Aug 2014 11:45:45 -0700 (PDT)
Raw View
------=_Part_2598_523078379.1407869145699
Content-Type: text/plain; charset=UTF-8
I'm going to suggest a new method of returning data from a function. The
usage of dynamic return.
I will demonstrate the general idea here:
#include <iostream>
void bar (int)
{
std::cout << "int" << std::endl;
};
void bar (float)
{
std::cout << "float" << std::endl;
};
<int, float> foo (int i)
{
if (i > 10) return[0] i;
else return[1] (float) i;
};
int main()
{
int i;
std::cin >> i;
bar(foo(i));
}
In order to use this syntax, the return value would be part of the concrete
type of the function. A caller must define all possible return paths, and
you can only return from one return path.
The following syntax can be supported for multiple return calls:
virtual switch (auto a = foo(i))
{
case 0:
std::cout << "an int: " << a << std::endl;
break;
case 1:
std::cout << "a float: " << a << std::endl;
break;
}
If you fall through from one label to another, if the type is able to be
converted (such as a pointer to derived to base) to the final type of the
value before any code other than case statements, then this conversion
shall occur, otherwise the program is ill-formed. The type of a in default
may be void.
Rather than return[n], in cases where some return type does not occur
multiple times, you may return<T>, likewise, if a return type only occurs
once, you may switch on it via case T:.
Individual case T statements may be marked virtual, in this case, the
program shall attempt to dynamic-cast to the type of the case. If this
succeeds, then the statement shall execute, otherwise it shall continune on.
For example:
class A
{
};
class B : public A
{
};
class C: public A
{
};
<A*, int> foo (int i)
{
if (i == 1) return<A*> new B;
if (i == 2) return<A*> new C;
return<int> 0;
};
int main()
{
int i;
std::cin>>i;
virtual switch(auto a = foo(i))
{
virtual case B*:
std::cout<<"B!"<<std::endl;
break;
virtual case C*:
std::cout<<"C!"<<std::endl;
break;
case int:
std::cout<<"int"<<std::endl;
break;
default:
std::cout<<"unexpected result, here typeof(a) == typeof(void)"<<std::
endl;
}
};
Suggestions?
--
---
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_2598_523078379.1407869145699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm going to suggest a new method of returning data from a=
function. The usage of dynamic return.<br>I will demonstrate the general i=
dea here:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">#include</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify"><io=
stream></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">vo=
id</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy">"int"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> bar </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">float<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">cout </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: #080;" class=3D"=
styled-by-prettify">"float"</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">float</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i </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: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">return</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">else</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">1</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: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> main</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cin </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">>></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> bar</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">foo=
</span><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 style=
=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><br>In order to use =
this syntax, the return value would be part of the concrete type of the fun=
ction. A caller must define all possible return paths, and you can only ret=
urn from one return path.<br><br>The following syntax can be supported for =
multiple return calls:<br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">switch</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">case</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"st=
yled-by-prettify">"an int: "</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
td</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">case</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"a floa=
t: "</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">break</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> <br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br></span></div></code></div><br>If you fall through=
from one label to another, if the type is able to be converted (such as a =
pointer to derived to base) to the final type of the value before any code =
other than case statements, then this conversion shall occur, otherwise the=
program is ill-formed. The type of a in default may be void. <br><br>Rathe=
r than return[n], in cases where some return type does not occur multiple t=
imes, you may return<T>, likewise, if a return type only occurs once,=
you may switch on it via case T:.<br><br>Individual case T statements may =
be marked virtual, in this case, the program shall attempt to dynamic-cast =
to the type of the case. If this succeeds, then the statement shall execute=
, otherwise it shall continune on.<br>For example:<br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> A<br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> B </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> A<br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> C</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: #008;" class=3D"styled-by-prettify">publi=
c</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A<br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">A</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</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">return</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">A</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>*></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">new</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">i </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">A</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">new</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify"><int></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> <br><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">cin</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">>></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">i</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">switch</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">"B!"</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">break</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">virtual</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">*:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> std</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">cout</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><<</span><span style=3D"color: #080;" class=3D"styled-by-prettify">=
"C!"</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">cout</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><<</span><span style=3D"color: #080;" 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=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">brea=
k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">default</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">"unexpected result, =
here typeof(a) =3D=3D typeof(void)"</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">endl</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; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>Suggestions?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2598_523078379.1407869145699--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 12 Aug 2014 15:25:52 -0400
Raw View
--001a1133f016ca086f050073a3b0
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 12, 2014 at 2:45 PM, <r.p.nicholl@gmail.com> wrote:
Suggestions?
>
Why not just return a boost::variant?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1133f016ca086f050073a3b0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Aug 12, 2014 at 2:45 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:r.p.nicholl@gmail.com" target=3D"_blank">r.p.nicholl@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><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">Suggestions?<span class=3D"=
HOEnZb"><font color=3D"#888888"><br></font></span></div><span class=3D"HOEn=
Zb"></span></blockquote>
</div><br></div><div class=3D"gmail_extra">Why not just return a boost::var=
iant?<br clear=3D"all"></div><div class=3D"gmail_extra"><br>-- <br>Zhihao Y=
uan, ID lichray<br>The best way to predict the future is to invent it.<br>_=
__________________________________________________<br>
4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http://bit.ly/=
blog4bsd</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133f016ca086f050073a3b0--
.
Author: r.p.nicholl@gmail.com
Date: Tue, 12 Aug 2014 15:02:22 -0700 (PDT)
Raw View
------=_Part_2733_421930121.1407880942135
Content-Type: text/plain; charset=UTF-8
This is not the same thing. boost::variant allows you "multiple type,
single value", this allows you "single type, single value", but "multiple
possible return pathways". I think the distinction is important. So your
"get_string" might return a std::string const& or std::string && depending
on how many references it counts to the std::string accessed by a
shared_ptr (if it's the only user, it will steal the value!). True, this
could be done through callbacks, but the overhead is unacceptable, the code
resulting is more verbose and difficult to read.
Because I would like my code to not be as slow as molasses I would like
this feature. This feature could potentially improve speed in a way that
would allow it to outspeed C in many circumstances. This would have the
speed of a cross function goto jump in the case of simple return
statements, even where the type deduction can not be guaranteed by the
compiler.
This simply allows you to write fast code which is not ugly. Lambdas have
construction and destruction penalties, and are as slow or slower than
function pointers vs ordinary functions.
Switching on a union requires unnecessary comparisons by the caller, who
could simply have passed multiple pathways to the callee who chooses for
them (in the same branch they choose what type to return).
This could also be inlined, lambdas I assume, are not so easily inlined.
There is less room for error here with little room for undefined behaviour,
vs unions.
On Tuesday, August 12, 2014 3:25:57 PM UTC-4, Zhihao Yuan wrote:
>
> On Tue, Aug 12, 2014 at 2:45 PM, <r.p.n...@gmail.com <javascript:>> wrote:
>
> Suggestions?
>>
>
> Why not just return a boost::variant?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://bit.ly/blog4bsd
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2733_421930121.1407880942135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is not the same thing. boost::variant allows you "mul=
tiple type, single value", this allows you "single type, single value", but=
"multiple possible return pathways". I think the distinction is important.=
So your "get_string" might return a std::string const& or std::string =
&& depending on how many references it counts to the std::string ac=
cessed by a shared_ptr (if it's the only user, it will steal the value!). T=
rue, this could be done through callbacks, but the overhead is unacceptable=
, the code resulting is more verbose and difficult to read.<br><br>Because =
I would like my code to not be as slow as molasses I would like this featur=
e. This feature could potentially improve speed in a way that would allow i=
t to outspeed C in many circumstances. This would have the speed of a cross=
function goto jump in the case of=20
simple return statements, even where the type deduction can not be=20
guaranteed by the compiler. <br><br>This simply allows you to write fast co=
de which is not ugly. Lambdas have construction and destruction penalties, =
and are as slow or slower than function pointers vs ordinary functions.<br=
>Switching on a union requires unnecessary comparisons by the caller, who c=
ould simply have passed multiple pathways to the callee who chooses for the=
m (in the same branch they choose what type to return). <br>This could also=
be inlined, lambdas I assume, are not so easily inlined.<br><br>There is l=
ess room for error here with little room for undefined behaviour, vs unions=
..<br><br>On Tuesday, August 12, 2014 3:25:57 PM UTC-4, Zhihao Yuan wrote:<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">On Tue, Aug 12,=
2014 at 2:45 PM, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"SnKiicCG5d8J" onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:';return true=
;">r.p.n...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quo=
te"><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">Suggestions?<span><font col=
or=3D"#888888"><br></font></span></div><span></span></blockquote>
</div><br></div><div>Why not just return a boost::variant?<br clear=3D"all"=
></div><div><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict t=
he future is to invent it.<br>______________________________<wbr>__________=
___________<br>
4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank" onmousedown=3D=
"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\=
46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiCyQ';return tru=
e;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.=
ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiC=
yQ';return true;">http://bit.ly/blog4bsd</a>
</div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2733_421930121.1407880942135--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 12 Aug 2014 18:34:15 -0400
Raw View
--001a11c3678c7fff430500764532
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 12, 2014 at 6:02 PM, <r.p.nicholl@gmail.com> wrote:
> This is not the same thing. boost::variant allows you "multiple type,
> single value", this allows you "single type, single value", but "multiple
> possible return pathways".
>
boost::variant is one type for a set of types, and you can of
course use multiple return pathways constructing boost::variant,
and the `switch` is done internally behind a visitor interface (try
https://gist.github.com/gintenlabo/6363346).
> I think the distinction is important. So your "get_string" might return a
> std::string const& or std::string && depending on how many references it
> counts to the std::string accessed by a shared_ptr (if it's the only user,
> it will steal the value!).
>
User side code still needs to do a `virtual switch`, so your
system merely translated the knowledge of use_count()
into the knowledge of switch cases, I don't think that eases
the use. Asking user to check use_count() looks more
reasonable to me.
> Because I would like my code to not be as slow as molasses I would like
> this feature. This feature could potentially improve speed in a way that
> would allow it to outspeed C in many circumstances. This would have the
> speed of a cross function goto jump in the case of simple return
> statements, even where the type deduction can not be guaranteed by the
> compiler.
>
Adding a language feature does not mandate any optimization,
while not adding a language feature does not forbid an
optimization to do the same thing.
> This simply allows you to write fast code which is not ugly. Lambdas have
> construction and destruction penalties, and are as slow or slower than
> function pointers vs ordinary functions.
> [...]
> This could also be inlined, lambdas I assume, are not so easily inlined.
>
I don't think those claims above are true.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3678c7fff430500764532
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Aug 12, 2014 at 6:02 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:r.p.nicholl@gmail.com" target=3D"_blank">r.p.nicholl@gmail.=
com</a>></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:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">This is not the same thing. boost::variant allows you &quo=
t;multiple type, single value", this allows you "single type, sin=
gle value", but "multiple possible return pathways".</div>
</blockquote><div><br></div><div>boost::variant is one type for a set of ty=
pes, and you can of<br>course use multiple return pathways constructing boo=
st::variant,<br>and the `switch` is done internally behind a visitor interf=
ace (try<br>
<a href=3D"https://gist.github.com/gintenlabo/6363346">https://gist.github.=
com/gintenlabo/6363346</a>).<br></div><div>=C2=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">I think the distinction is important. So your "get_st=
ring" might return a std::string const& or std::string && =
depending on how many references it counts to the std::string accessed by a=
shared_ptr (if it's the only user, it will steal the value!).<br>
</div></blockquote><div><br></div><div>User side code still needs to do a `=
virtual switch`, so your<br></div><div>system merely translated the knowled=
ge of use_count()<br></div><div>into the knowledge of switch cases, I don&#=
39;t think that eases<br>
</div><div>the use.=C2=A0 Asking user to check use_count() looks more<br></=
div><div>reasonable to me.<br></div><div>=C2=A0</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">
Because I would like my code to not be as slow as molasses I would like thi=
s feature. This feature could potentially improve speed in a way that would=
allow it to outspeed C in many circumstances. This would have the speed of=
a cross function goto jump in the case of=20
simple return statements, even where the type deduction can not be=20
guaranteed by the compiler. <br></div></blockquote><div><br></div><div>Addi=
ng a language feature does not mandate any optimization,<br></div><div>whil=
e not adding a language feature does not forbid an<br>optimization to do th=
e same thing.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>This simply a=
llows you to write fast code which is not ugly. Lambdas have construction a=
nd destruction penalties, and are as slow or slower than function pointers=
vs ordinary functions.<br>
[...]<br>This could also be inlined, lambdas I assume, are not so easily in=
lined.<br></div></blockquote></div><br></div><div class=3D"gmail_extra">I d=
on't think those claims above are true.<br clear=3D"all"></div><div cla=
ss=3D"gmail_extra">
<br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict the future is=
to invent it.<br>___________________________________________________<br>4B=
SD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http://bit.ly/bl=
og4bsd</a>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3678c7fff430500764532--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 12 Aug 2014 16:06:26 -0700 (PDT)
Raw View
------=_Part_4240_2067440126.1407884786622
Content-Type: text/plain; charset=UTF-8
I think this idea has some merit if peeled down to a smaller definition.
The use case I think of is mainly for error returns.
The function is declared to return for instance its real return type or an
error code. Now the compiler will enforce that you actually take care of
the error condition by enclosing the call in a switch with an int case.
The entire mechanism is rather similar to a try/catch/throw but with the
difference that the compiler checks that all types are handled on the
immediately enclosing level.
I would rate this feature as rather useful, but it is nothing I would
scream for.
The ideas of virtual cases and being able to call overloaded functions
based on the return type seems a bit over the top to me, as it creates so
much invisible machinery.
Allowing immediate re-returning of a set of types you got from a called
function seems a logical extension but has some of the drawback of the old
throw specifications in that the number of types involved can get unwieldy.
Finally I would like to see the switch also being able to branch out on
values, not just types. Maybe this could be an embryo of a more general
match functionality?
As for the boost::variant suggestion I don't think the compiler gets at all
the same possibilities to do something smart for such a library solution.
Den tisdagen den 12:e augusti 2014 kl. 21:25:57 UTC+2 skrev Zhihao Yuan:
>
> On Tue, Aug 12, 2014 at 2:45 PM, <r.p.n...@gmail.com <javascript:>> wrote:
>
> Suggestions?
>>
>
> Why not just return a boost::variant?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://bit.ly/blog4bsd
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4240_2067440126.1407884786622
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think this idea has some merit if peeled down to a small=
er definition. The use case I think of is mainly for error returns.<div><br=
></div><div>The function is declared to return for instance its real return=
type or an error code. Now the compiler will enforce that you actually tak=
e care of the error condition by enclosing the call in a switch with an int=
case.</div><div><br></div><div>The entire mechanism is rather similar to a=
try/catch/throw but with the difference that the compiler checks that all =
types are handled on the immediately enclosing level.</div><div><br></div><=
div>I would rate this feature as rather useful, but it is nothing I would s=
cream for.</div><div><br></div><div>The ideas of virtual cases and being ab=
le to call overloaded functions based on the return type seems a bit over t=
he top to me, as it creates so much invisible machinery.</div><div><br></di=
v><div>Allowing immediate re-returning of a set of types you got from a cal=
led function seems a logical extension but has some of the drawback of the =
old throw specifications in that the number of types involved can get unwie=
ldy.</div><div><br></div><div>Finally I would like to see the switch also b=
eing able to branch out on values, not just types. Maybe this could be an e=
mbryo of a more general match functionality?</div><div><br></div><div>As fo=
r the boost::variant suggestion I don't think the compiler gets at all the =
same possibilities to do something smart for such a library solution.</div>=
<div><br></div><div><br></div><div><div><br><br>Den tisdagen den 12:e augus=
ti 2014 kl. 21:25:57 UTC+2 skrev Zhihao Yuan:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">On Tue, Aug 12, 2014 at 2:45 PM, <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"SnKiicCG5d8J" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">r.p.n...@gmail.com</a>>=
;</span> wrote:<br><div><div class=3D"gmail_quote"><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">Suggestions?<span><font col=
or=3D"#888888"><br></font></span></div><span></span></blockquote>
</div><br></div><div>Why not just return a boost::variant?<br clear=3D"all"=
></div><div><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict t=
he future is to invent it.<br>______________________________<wbr>__________=
___________<br>
4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank" onmousedown=3D=
"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\=
46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiCyQ';return tru=
e;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.=
ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiC=
yQ';return true;">http://bit.ly/blog4bsd</a>
</div></div>
</blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4240_2067440126.1407884786622--
.
Author: r.p.nicholl@gmail.com
Date: Tue, 12 Aug 2014 16:11:14 -0700 (PDT)
Raw View
------=_Part_683_661024102.1407885074173
Content-Type: text/plain; charset=UTF-8
>
> boost::variant is one type for a set of types, and you can of
> course use multiple return pathways constructing boost::variant,
> and the `switch` is done internally behind a visitor interface (try
> https://gist.github.com/gintenlabo/6363346).
>
Unfortunately the code you linked does not provide the same functionality.
It is both neat and completely irrelevant. I will not comment on it further
as it does not implement the same features.
User side code still needs to do a `virtual switch`, so your
> system merely translated the knowledge of use_count()
> into the knowledge of switch cases, I don't think that eases
> the use.
>
Sorry, but you didn't read everything I posted. virtual switch was not the
only interface to this functionality. Where multiple overloads of a
function support all of the return types, it is supported to call the
function directly. Also if the implicit conversions of such may convert it
to a proper overload through normal argument resolution rules. While
virtual switch may not be the best interface, I provided it as only one
example. The syntax for non-overloading returns should probably be improved.
Asking user to check use_count() looks more
> reasonable to me.
All progress requires unreasonable people who prefer to change the world
rather than adapt to it. I find that not requiring it is more conducive to
progress. Consider:
std::string s(std::move(obj).get_string());
std::string s2(std::move(obj2).get_string());
std::string s3(std::move(obj3).get_string());
vs whatever else you can come up with.
Now assuming we can not edit std::string to accept a boost::variant, what
code would we replace that with in order to ensure that the string is
copied or moved appropriately? I Oh, but you could return a std::string and
select the operation in get_string? That works great,* unless you only want
to read the value*, rather than make a copy. I leave it as an exercise to
the reader to come up with the replacement.
Adding a language feature does not mandate any optimization,
> while not adding a language feature does not forbid an
> optimization to do the same thing.
Yes, under this logic JavaScript should run as fast as FORTRAN right? Since
only the result matters! If the compiler can just figure out that this here
is always a float and make it statically typed, and this here is always
a... and this is doing this...
Actually, something called *practice* gets in the way of *theory*. The fact
is, compilers are somewhat stupid. Compiler technology improvements double
the speed of programs *every 18 years*. Low-level code just plain runs
faster, no one has made a perfect compiler that can translate all high
level code into perfect low level code.
I don't think those claims above are true.
Which part?
Fact: you can't inline a std::function operator() call at compile time if
the function's assigned value is defined in another compilation area, such
as a plugin.
Fact: there is overhead for calling function pointers or std::functions
when not fully inline.
Fact: there is extra overhead for checking the "type" parameter of some
value if not inlined.
Fact: there is not extra overhead in returning to one of several return
pointers vs switching on a "return index" in the caller. Except for the
possibility of strange branch prediction CPU weirdness.
Theory: This may even speed up the code, as the branch prediction features
of the CPU probably would be able to predict the type more easily ahead of
time, and the type is tied to the branch.
Fact: If the above theory is true, this would work even if the code is not
inlined.
On Tuesday, August 12, 2014 6:34:18 PM UTC-4, Zhihao Yuan wrote:
>
> On Tue, Aug 12, 2014 at 6:02 PM, <r.p.n...@gmail.com <javascript:>> wrote:
>
>> This is not the same thing. boost::variant allows you "multiple type,
>> single value", this allows you "single type, single value", but "multiple
>> possible return pathways".
>>
>
> boost::variant is one type for a set of types, and you can of
> course use multiple return pathways constructing boost::variant,
> and the `switch` is done internally behind a visitor interface (try
> https://gist.github.com/gintenlabo/6363346).
>
>
>> I think the distinction is important. So your "get_string" might return a
>> std::string const& or std::string && depending on how many references it
>> counts to the std::string accessed by a shared_ptr (if it's the only user,
>> it will steal the value!).
>>
>
> User side code still needs to do a `virtual switch`, so your
> system merely translated the knowledge of use_count()
> into the knowledge of switch cases, I don't think that eases
> the use. Asking user to check use_count() looks more
> reasonable to me.
>
>
>> Because I would like my code to not be as slow as molasses I would like
>> this feature. This feature could potentially improve speed in a way that
>> would allow it to outspeed C in many circumstances. This would have the
>> speed of a cross function goto jump in the case of simple return
>> statements, even where the type deduction can not be guaranteed by the
>> compiler.
>>
>
> Adding a language feature does not mandate any optimization,
> while not adding a language feature does not forbid an
> optimization to do the same thing.
>
>
>> This simply allows you to write fast code which is not ugly. Lambdas have
>> construction and destruction penalties, and are as slow or slower than
>> function pointers vs ordinary functions.
>> [...]
>> This could also be inlined, lambdas I assume, are not so easily inlined.
>>
>
> I don't think those claims above are true.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://bit.ly/blog4bsd
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_683_661024102.1407885074173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
boost::variant is one type for a set of types, and you can of<br>course use=
multiple return pathways constructing boost::variant,<br>and the `switch` =
is done internally behind a visitor interface (try<br>
<a href=3D"https://gist.github.com/gintenlabo/6363346" target=3D"_blank">ht=
tps://gist.github.com/<wbr>gintenlabo/6363346</a>).<br></blockquote><div>&n=
bsp;</div><div>Unfortunately the code you linked does not provide the same=
=20
functionality. It is both neat and completely irrelevant. I will not commen=
t on it further as it does not=20
implement the same features. <br><br><blockquote style=3D"margin: 0px 0px 0=
px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" cl=
ass=3D"gmail_quote"><div>User side code still needs to do a `virtual switch=
`, so your<br></div><div>system merely translated the knowledge of use_coun=
t()<br></div><div>into the knowledge of switch cases, I don't think that ea=
ses<br>
</div>the use. <br></blockquote></div><div> </div>Sorry, b=
ut you didn't read everything I posted. virtual switch was not the only int=
erface to this functionality. Where multiple overloads of a function suppor=
t all of the return types, it is supported to call the function directly. A=
lso if the implicit conversions of such may convert it to a proper overload=
through normal argument resolution rules. While virtual switch may not be =
the best interface, I provided it as only one example. The syntax for non-o=
verloading returns should probably be improved.<br><br><br><blockquote styl=
e=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;" class=3D"gmail_quote">Asking user to check use_count() =
looks more<br>reasonable to me.</blockquote><br>All progress requires unrea=
sonable people who prefer to change the world rather than adapt to it. I fi=
nd that not requiring it is more conducive to progress. Consider:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">obj<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">).</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">get_string</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">());</span><br><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">std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">2(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>obj</span><span style=3D"color: #660;" class=3D"styled-by-prettify">2).</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">get_string</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">());</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></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"color: #000;" class=3D"styled-by=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">stri=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">3(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">move</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">obj</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">3).</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">get_string</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">());</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></code></span></code></span></div></code></div><br>vs whatever =
else you can come up with.<br><br>Now assuming we can not edit std::string =
to accept a boost::variant, what code would we replace that with in order t=
o ensure that the string is copied or moved appropriately? I Oh, but you co=
uld return a std::string and select the operation in get_string? That works=
great,<i> unless you only want to <b>read</b> the value</i>, rather than m=
ake a copy. I leave it as an exercise to the reader to come up with the rep=
lacement.<br><br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quo=
te"><div>Adding a language feature does not mandate any optimization,<br></=
div>while not adding a language feature does not forbid an<br>optimization =
to do the same thing.</blockquote><br>Yes, under this logic JavaScript shou=
ld run as fast as FORTRAN right? Since only the result matters! If the comp=
iler can just figure out that this here is always a float and make it stati=
cally typed, and this here is always a... and this is doing this...<br>Actu=
ally, something called <b>practice</b> gets in the way of <b>theory</b>. Th=
e fact is, compilers are somewhat stupid. Compiler technology improvements =
double the speed of programs <i>every 18 years</i>. Low-level code just pla=
in runs faster, no one has made a perfect compiler that can translate all h=
igh level code into perfect low level code.<br><br><br><blockquote style=3D=
"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padd=
ing-left: 1ex;" class=3D"gmail_quote">I don't think those claims above are =
true.</blockquote><br>Which part?<br><br>Fact: you can't inline a std::func=
tion operator() call at compile time if the function's assigned value is de=
fined in another compilation area, such as a plugin.<br>Fact: there is over=
head for calling function pointers or std::functions when not fully inline.=
<br>Fact: there is extra overhead for checking the "type" parameter of some=
value if not inlined.<br>Fact: there is not extra overhead in returning to=
one of several return pointers vs switching on a "return index" in the cal=
ler. Except for the possibility of strange branch prediction CPU weirdness.=
<br>Theory: This may even speed up the code, as the branch prediction featu=
res of the CPU probably would be able to predict the type more easily ahead=
of time, and the type is tied to the branch.<br>Fact: If the above theory =
is true, this would work even if the code is not inlined.<br><br>On Tuesday=
, August 12, 2014 6:34:18 PM UTC-4, Zhihao Yuan wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">On Tue, Aug 12, 2014 at 6:02 PM, =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"7rFjcpH4eacJ" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">r.p.n...@gmail.c=
om</a>></span> wrote:<br><div><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr">This is not the same thing. boost::variant allows you "mul=
tiple type, single value", this allows you "single type, single value", but=
"multiple possible return pathways".</div>
</blockquote><div><br></div><div>boost::variant is one type for a set of ty=
pes, and you can of<br>course use multiple return pathways constructing boo=
st::variant,<br>and the `switch` is done internally behind a visitor interf=
ace (try<br>
<a href=3D"https://gist.github.com/gintenlabo/6363346" target=3D"_blank" on=
mousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgist=
..github.com%2Fgintenlabo%2F6363346\46sa\75D\46sntz\0751\46usg\75AFQjCNF9ldn=
xN24wDCehP-90Z-XScOFdrw';return true;" onclick=3D"this.href=3D'https://www.=
google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fgintenlabo%2F6363346\46s=
a\75D\46sntz\0751\46usg\75AFQjCNF9ldnxN24wDCehP-90Z-XScOFdrw';return true;"=
>https://gist.github.com/<wbr>gintenlabo/6363346</a>).<br></div><div> =
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">I think the distinction is important. So your "get_string"=
might return a std::string const& or std::string && depending =
on how many references it counts to the std::string accessed by a shared_pt=
r (if it's the only user, it will steal the value!).<br>
</div></blockquote><div><br></div><div>User side code still needs to do a `=
virtual switch`, so your<br></div><div>system merely translated the knowled=
ge of use_count()<br></div><div>into the knowledge of switch cases, I don't=
think that eases<br>
</div><div>the use. Asking user to check use_count() looks more<br></=
div><div>reasonable to me.<br></div><div> </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">
Because I would like my code to not be as slow as molasses I would like thi=
s feature. This feature could potentially improve speed in a way that would=
allow it to outspeed C in many circumstances. This would have the speed of=
a cross function goto jump in the case of=20
simple return statements, even where the type deduction can not be=20
guaranteed by the compiler. <br></div></blockquote><div><br></div><div>Addi=
ng a language feature does not mandate any optimization,<br></div><div>whil=
e not adding a language feature does not forbid an<br>optimization to do th=
e same thing.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>This simply a=
llows you to write fast code which is not ugly. Lambdas have construction a=
nd destruction penalties, and are as slow or slower than function pointers=
vs ordinary functions.<br>
[...]<br>This could also be inlined, lambdas I assume, are not so easily in=
lined.<br></div></blockquote></div><br></div><div>I don't think those claim=
s above are true.<br clear=3D"all"></div><div>
<br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict the future is=
to invent it.<br>______________________________<wbr>_____________________<=
br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2Fblog4b=
sd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiCyQ';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fb=
it.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnCr7FA=
kiCyQ';return true;">http://bit.ly/blog4bsd</a>
</div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_683_661024102.1407885074173--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 12 Aug 2014 19:08:26 -0700
Raw View
On Tuesday 12 August 2014 11:45:45 r.p.nicholl@gmail.com wrote:
> In order to use this syntax, the return value would be part of the concrete
> type of the function. A caller must define all possible return paths, and
> you can only return from one return path.
Do you intend for this to be usable with non-inline functions?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Ryan P. Nicholl" <r.p.nicholl@gmail.com>
Date: Tue, 12 Aug 2014 22:12:50 -0400
Raw View
Absolutely, a return type of <T, T2...> would be part of the ABI. Instead of pushing one return address on the call, you push every return path and the callee jumps to the correct one on return.
On August 12, 2014 10:08:26 PM EDT, Thiago Macieira <thiago@macieira.org> wrote:
>On Tuesday 12 August 2014 11:45:45 r.p.nicholl@gmail.com wrote:
>> In order to use this syntax, the return value would be part of the
>concrete
>> type of the function. A caller must define all possible return paths,
>and
>> you can only return from one return path.
>
>Do you intend for this to be usable with non-inline functions?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 12 Aug 2014 20:45:47 -0700
Raw View
On Tuesday 12 August 2014 22:12:50 Ryan P. Nicholl wrote:
> Absolutely, a return type of <T, T2...> would be part of the ABI. Instead of
> pushing one return address on the call, you push every return path and the
> callee jumps to the correct one on return.
So you're describing a return type containing a type ID and storage space for
a list of possible types.
This can be done with a library solution. Why do we need a language feature?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Ryan P. Nicholl" <r.p.nicholl@gmail.com>
Date: Tue, 12 Aug 2014 23:59:58 -0400
Raw View
And no, I'm not describing that. Again another person doesn't read the original message. You can not do std::string::string(boost::variant).
Other than that, my response to your logic is this:
C++ should not include generic typing, because you can include a library which emulates a i386 PC in C++, boot linux on that, then run java in that which supports generic typing.
Ok, regardless of your position on generic typing, I think I made my point, even if a little extreme of an example. The fact is, brainfuck is turing complete. Just because something can be done doesn't make it optimal.
A language feature would provide a standard interface and would also work with old code (like std::string.)
It would be much faster too.
On August 12, 2014 11:45:47 PM EDT, Thiago Macieira <thiago@macieira.org> wrote:
>On Tuesday 12 August 2014 22:12:50 Ryan P. Nicholl wrote:
>> Absolutely, a return type of <T, T2...> would be part of the ABI.
>Instead of
>> pushing one return address on the call, you push every return path
>and the
>> callee jumps to the correct one on return.
>
>So you're describing a return type containing a type ID and storage
>space for
>a list of possible types.
>
>This can be done with a library solution. Why do we need a language
>feature?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 13 Aug 2014 11:02:44 +0800
Raw View
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;" dir=3D"auto"><div>Now =
I see what you’re proposing. This proposal barely regards types at al=
l; it’s really a control flow construct.</div><div><br></div><div>Pus=
hing multiple return addresses on the stack would work, but very slowly. Br=
anch predictors universally assume that a function return will jump to just=
after the call instruction. Doing otherwise nets a branch misprediction pi=
peline flush.</div><div><br></div><div>It’s faster just to return som=
e kind of discriminated union and dispatch on the discriminator. <font face=
=3D"Courier">boost::variant</font> might be unsuitable because it disallows=
duplicate types, but you can still roll your own without too much hassle. =
(You don’t need all of <font face=3D"Courier">variant</font>’s =
features.)</div><div><br></div><br><div><div>On 2014–08–13, at =
10:12 AM, Ryan P. Nicholl <<a href=3D"mailto:r.p.nicholl@gmail.com">r.p.=
nicholl@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-newlin=
e"><blockquote type=3D"cite">Absolutely, a return type of <T, T2...> =
would be part of the ABI. Instead of pushing one return address on the call=
, you push every return path and the callee jumps to the correct one on ret=
urn.<br></blockquote></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 13 Aug 2014 10:39:41 +0200
Raw View
--089e011842a6aa651c05007eba00
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If I =E2=80=8Bunderstand correctly, such a function using the proposed retu=
rn
system would
- only be usable if inline;
- deduce the return type at compile time;
I can see some use but not a generalisation.
The interesting idea is to rely on compile-time instead of runtime like for
exceptions.
However, I would like to see examples of code that would definitely benefit
to have such a feature.
--=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/.
--089e011842a6aa651c05007eba00
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If I=C2=A0=E2=80=8Bunderstand correctly, such a function u=
sing the proposed return system would=C2=A0<div>=C2=A0- only be usable if i=
nline;</div><div>=C2=A0- deduce the return type at compile time;</div><div>=
<br></div><div>I can see some use but not a generalisation.</div>
<div>The interesting idea is to rely on compile-time instead of runtime lik=
e for exceptions.</div><div><br></div><div>However, I would like to see exa=
mples of code that would definitely benefit to have such a feature.</div>
<div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011842a6aa651c05007eba00--
.
Author: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= <dibeas@ieee.org>
Date: Wed, 13 Aug 2014 10:15:13 -0400
Raw View
--001a1135637ea961b50500836af3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I see different things in the original code that I did not quite grasp in
the first read. It might be good if you went through a more detailed
description of the different things that you want and how you believe can
be implemented. That would possibly clarify points that others (i.e. me)
might have missed.
For starters, it seems from a later comment that you don't want to provide
syntactic sugar around a single return type that mimics 'one_of<A,B,C>' but
rather have a control flow structure in which the callee will return to
different addresses depending on what return was hit. In the first example
you want 'main' to look something like (pseudo code):
int main() {
int i;
std::cin >> i;
[[uninitialized]] union { int i; float f } __return;
foo(&__return, i);
return_int:
// buffer holds an 'int'
bar(__return.i);
return 0;
return_float:
// buffer holds a 'float'
bar(__return.f);
return 0;
}
Where it is 'foo' who makes the decision as of which label to return to
(multiple return addresses passed to 'foo', foo jumps back to one of them).
void foo(union { int i; float f; } *__return; int i) {
if (i > 10) {
new (__return->i) int(i);
return return_int;
} else {
new (__return->f) float(i);
return return_float;
}
}
I am not sure if this construct would be reduced to being used directly as
part of an immediate function call or "virtual switch" or if you want to
support other use cases. If other cases need to be supported, the code
above can turn into a fair amount of different code paths each of which
might amount to as much as the remainder of the function. Consider:
void f(int i) {
auto a =3D foo(i);
auto b =3D foo(i + 5);
auto c =3D foo(i - 5);
// Some code here that uses a, b, c
}
That "simple" piece of code has 8 different possible combinations of types
for (a,b,c), which means that "// some code here" behaves as a template
that is specialized for the 8 different cases, possibly contributing to a
fair amount of code bloat. I am not saying that if that is what your
program needs there are better alternatives, but it becomes a bit less
obvious to reason about code. I don't love the idea of 'auto' everywhere as
it hides the actual type, but this goes one step beyond, you cannot reason
about the type even if you see the declaration of the function!
If only the immediate function call is to be supported this can be
trivially written in C++14 (I believe, I am still writing C++03, bear with
me):
template <typename T>
void foo(int i, T continuation) {
if (i > 10) continuation(i);
else continuation(static_cast<float>(i));
}
int main() {
int i;
std::cin >> i;
foo(i, [](auto x) { bar(x); });
}
Now, a completely different feature is mentioned in the original message:
virtual switch(auto a =3D foo(i)) {
virtual case B*: std::cout<<"B!"<<std::endl; break;
virtual case C*: std::cout<<"C!"<<std::endl; break;
This is hiding an unrelated feature, the compiler matching *dynamic* types.
I consider this feature almost orthogonal to the other in the sense that
you could do the same thing with 'A* foo(int)' (single, simple, currrent
form of return type) although it complements the other feature in enriching
the possibilities. The code in that switch (assuming single return type),
could be simply translated to:
auto a =3D foo(i);
if (dynamic_cast<B*>(a)) { std::cout << "B!\n"; }
else if (dynamic_cast<C*>(a)) { std::cout << "C!\n"; }
And without that assumption (i.e. considering the set of return types as in
the first part) that would be what the 'return_A_ptr' label would have to
look like. Note that this requires that the compiler sees the definition of
the types 'A', 'B' and 'C' to be able to perform the 'dynamic_cast'. Except
that both features don't quite mix cleanly. Consider this modified 'foo'
version:
<A*, B*, int> foo (int i)
{
if (i =3D=3D 1) return<A*> new B;
if (i =3D=3D 2) return<A*> new C;
if (i =3D=3D 3) return<B*> new B;
return<int> 0;
};
virtual switch(auto a =3D foo(i))
{
virtual case B*: std::cout<<"B!"<<std::endl; break;
virtual case C*: std::cout<<"C!"<<std::endl; break;
When should the 'virtual case B*' be hit? When the function returns 'B*' or
also when it returns 'A*' which may be really a 'B*'? At any rate the
definition of the types would need to be seen here. Note that in the case
of the function call, the compiler does not need to have the definition of
the types:
void bar(X*);
void bar(Y*);
{X*,Y*} foo();
bar(foo()); // Compiler only needs a declaration of X and Y for this
Personally I don't recall having needed this. I have needed to switch on a
runtime value to trigger different code paths, but I have solve that by
reading the value and then jumping to different functions (sometimes a
template), with a solution not that different from 'foo(i, [](auto x) {
bar(x); })' with the exception that in my case 'foo' was manually inlined
(or the call to bar was explicit in 'foo', not an argument to the function.
I would suggest that you think about the different features you want (the
two mentioned, any other that I might have missed), the problems that each
one of them solves and how much simpler the solution with the new feature
would be compared with the current state of the language. If you come up
with motivating examples the exact details and issues that you might have
missed can be further discussed.
David
On Wed, Aug 13, 2014 at 4:39 AM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.c=
om>
wrote:
> If I =E2=80=8Bunderstand correctly, such a function using the proposed re=
turn
> system would
> - only be usable if inline;
> - deduce the return type at compile time;
>
> I can see some use but not a generalisation.
> The interesting idea is to rely on compile-time instead of runtime like
> for exceptions.
>
> However, I would like to see examples of code that would definitely
> benefit to have such a feature.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1135637ea961b50500836af3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I see different things in the original code that I did not=
quite grasp in the first read. It might be good if you went through a more=
detailed description of the different things that you want and how you bel=
ieve can be implemented. That would possibly clarify points that others (i.=
e. me) might have missed.<br>
<br>For starters, it seems from a later comment that you don't want to =
provide syntactic sugar around a single return type that mimics 'one_of=
<A,B,C>' but rather have a control flow structure in which the ca=
llee will return to different addresses depending on what return was hit. I=
n the first example you want 'main' to look something like (pseudo =
code):<br>
<br><div>int main() {<br>=C2=A0 =C2=A0int i;<br>=C2=A0 =C2=A0std::cin >&=
gt; i;<br>=C2=A0 =C2=A0[[uninitialized]] union { int i; float f } __return;=
<br>=C2=A0 =C2=A0foo(&__return, i);<br>return_int:<br>=C2=A0 =C2=A0// b=
uffer holds an 'int'<br>=C2=A0 =C2=A0bar(__return.i);<br>
=C2=A0 =C2=A0return 0;<br>return_float:<br>=C2=A0 =C2=A0// buffer holds a &=
#39;float'<br>=C2=A0 =C2=A0bar(__return.f);<br>=C2=A0 =C2=A0return 0;<b=
r>}<br><br>Where it is 'foo' who makes the decision as of which lab=
el to return to (multiple return addresses passed to 'foo', foo jum=
ps back to one of them).=C2=A0<br>
<br>void foo(union { int i; float f; } *__return; int i) {<br>=C2=A0 =C2=A0=
if (i > 10) {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 new (__return->i) int(i=
);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return return_int;<br>=C2=A0 =C2=A0 } els=
e {<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 new (__return->f) float(i);<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 return return_float;<br>
=C2=A0 =C2=A0 }<br>}</div><br>I am not sure if this construct would be redu=
ced to being used directly as part of an immediate function call or "v=
irtual switch" or if you want to support other use cases. If other cas=
es need to be supported, the code above can turn into a fair amount of diff=
erent code paths each of which might amount to as much as the remainder of =
the function. Consider:<br>
<br>void f(int i) {<br>=C2=A0 =C2=A0 auto a =3D foo(i);<br>=C2=A0 =C2=A0 au=
to b =3D foo(i + 5);<br>=C2=A0 =C2=A0 auto c =3D foo(i - 5);<br>=C2=A0 =C2=
=A0 // Some code here that uses a, b, c<br>}<br><br>That "simple"=
piece of code has 8 different possible combinations of types for (a,b,c), =
which means that "// some code here" behaves as a template that i=
s specialized for the 8 different cases, possibly contributing to a fair am=
ount of code bloat. I am not saying that if that is what your program needs=
there are better alternatives, but it becomes a bit less obvious to reason=
about code. I don't love the idea of 'auto' everywhere as it h=
ides the actual type, but this goes one step beyond, you cannot reason abou=
t the type even if you see the declaration of the function!</div>
<div><br></div><div>If only the immediate function call is to be supported =
this can be trivially written in C++14 (I believe, I am still writing C++03=
, bear with me):<br><br>template <typename T><br>void foo(int i, T co=
ntinuation) {<br>
=C2=A0 =C2=A0if (i > 10) continuation(i);<br>=C2=A0 =C2=A0else continuat=
ion(static_cast<float>(i));<br>}<br>int main() {<br>=C2=A0 =C2=A0int =
i;<br>=C2=A0 =C2=A0std::cin >> i;<br>=C2=A0 =C2=A0foo(i, [](auto x) {=
bar(x); });<br>}<br><br>Now, a completely different feature is mentioned i=
n the original message:<br>
<br><div style=3D"background-color:rgb(250,250,250)"><font color=3D"#666600=
" face=3D"monospace" size=3D"1">=C2=A0 virtual switch(auto a =3D foo(i)) {<=
/font></div><div style=3D"background-color:rgb(250,250,250)"><font color=3D=
"#666600" face=3D"monospace" size=3D"1">=C2=A0 =C2=A0 virtual case B*:=C2=
=A0</font><span style=3D"color:rgb(102,102,0);font-family:monospace;font-si=
ze:x-small">std::cout<<"B!"<<std::endl;</span><span s=
tyle=3D"color:rgb(102,102,0);font-family:monospace;font-size:x-small">=C2=
=A0break;</span></div>
<div style=3D"background-color:rgb(250,250,250)"><font color=3D"#666600" fa=
ce=3D"monospace" size=3D"1">=C2=A0 =C2=A0 virtual case C*:</font><span styl=
e=3D"color:rgb(102,102,0);font-family:monospace;font-size:x-small">=C2=A0st=
d::cout<<"C!"<<std::endl;=C2=A0</span><span style=3D"=
color:rgb(102,102,0);font-family:monospace;font-size:x-small">break;</span>=
</div>
<div style=3D"background-color:rgb(250,250,250)"><br></div><div><span style=
=3D"background-color:rgb(255,255,255)"><br>This is hiding an unrelated feat=
ure, the compiler matching *dynamic* types. I consider this feature almost =
orthogonal to the other in the sense that you could do the same thing with =
'A* foo(int)' (single, simple, currrent form of return type) althou=
gh it complements the other feature in enriching the possibilities. =C2=A0T=
he code in that switch (assuming single return type), could be simply trans=
lated to:<br>
<br>auto a =3D foo(i);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (dynamic_cast<B*=
>(a)) { std::cout << "B!\n"; }<br>else if (dynamic_cast&=
lt;C*>(a)) { std::cout << "C!\n"; }<br><br>And without t=
hat assumption (i.e. considering the set of return types as in the first pa=
rt) that would be what the 'return_A_ptr' label would have to look =
like. Note that this requires that the compiler sees the definition of the =
types 'A', 'B' and 'C' to be able to perform the &#=
39;dynamic_cast'. Except that both features don't quite mix cleanly=
.. Consider this modified 'foo' version:<br>
<br><div><A*, B*, int> foo (int i)</div><div>{</div><div>=C2=A0 if (i=
=3D=3D 1) return<A*> new B;</div><div>=C2=A0 if (i =3D=3D 2) return&=
lt;A*> new C;<br>=C2=A0 if (i =3D=3D 3) return<B*> new B;</div><di=
v>=C2=A0 return<int> 0;</div>
<div>};<br><br><div>virtual switch(auto a =3D foo(i))</div><div>=C2=A0 {</d=
iv><div>=C2=A0 =C2=A0 virtual case B*: =C2=A0 =C2=A0 =C2=A0 std::cout<&l=
t;"B!"<<std::endl; =C2=A0 =C2=A0 =C2=A0 break;</div><div>=
=C2=A0 =C2=A0 virtual case C*: =C2=A0 =C2=A0 =C2=A0 std::cout<<"=
C!"<<std::endl; =C2=A0 =C2=A0 =C2=A0 break;<br>
<br>When should the 'virtual case B*' be hit? When the function ret=
urns 'B*' or also when it returns 'A*' which may be really =
a 'B*'? At any rate the definition of the types would need to be se=
en here. Note that in the case of the function call, the compiler does not =
need to have the definition of the types:<br>
<br>void bar(X*);<br>void bar(Y*);<br>{X*,Y*} foo();<br>bar(foo()); =C2=A0 =
=C2=A0 =C2=A0 =C2=A0// Compiler only needs a declaration of X and Y for thi=
s<br><br>Personally I don't recall having needed this. I have needed to=
switch on a runtime value to trigger different code paths, but I have solv=
e that by reading the value and then jumping to different functions (someti=
mes a template), with a solution not that different from 'foo(i, [](aut=
o x) { bar(x); })' with the exception that in my case 'foo' was=
manually inlined (or the call to bar was explicit in 'foo', not an=
argument to the function.<br>
<br>I would suggest that you think about the different features you want (t=
he two mentioned, any other that I might have missed), the problems that ea=
ch one of them solves and how much simpler the solution with the new featur=
e would be compared with the current state of the language. =C2=A0If you co=
me up with motivating examples the exact details and issues that you might =
have missed can be further discussed.<br>
<br>David</div></div></span></div></div></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Wed, Aug 13, 2014 at 4:39 AM, Klaim - J=
o=C3=ABl Lamotte <span dir=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com"=
target=3D"_blank">mjklaim@gmail.com</a>></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">If I=C2=A0=E2=80=8Bundersta=
nd correctly, such a function using the proposed return system would=C2=A0<=
div>=C2=A0- only be usable if inline;</div>
<div>=C2=A0- deduce the return type at compile time;</div><div><br></div><d=
iv>I can see some use but not a generalisation.</div>
<div>The interesting idea is to rely on compile-time instead of runtime lik=
e for exceptions.</div><div><br></div><div>However, I would like to see exa=
mples of code that would definitely benefit to have such a feature.</div>
<div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1135637ea961b50500836af3--
.
Author: "Ryan P. Nicholl" <r.p.nicholl@gmail.com>
Date: Wed, 13 Aug 2014 10:51:04 -0400
Raw View
I don't wish to support auto syntax except in a virtual switch statement. I=
think it would be nice to have, but I don't like the exponential complexit=
y growth problem. In that situation a variant would be more appropriate I t=
hink, although using this feature to construct the variant is not out of th=
e question.
As for if A* or B* is matched by vswitch, that is simple. If B inherits fro=
m A and you return along the A* path, then "case B*" will not match it, but=
"virtual case B*" will.=20
Modifying virtual switch on some considerations, will send new code soon.
The two cases I wish to support are:
funtion_with_overloads(foo());
and virtual switch.
My motivating example atm is to clean up code that could be rewritten by re=
turning a T&&, or T const&, or T&, or T etc. at runtime by checking a refer=
ence counter.=20
And for error checking.
Also differing size returns. (e.g. different code for u8 vs u32.)
Perhaps if you write "javascript add" for example as well, you would want t=
o be able to deal with an arbitrary type statically for speed even if you l=
ater stuff it into a variant.
I will send a code example soon.
On August 13, 2014 10:15:13 AM EDT, "David Rodr=C3=ADguez Ibeas" <dibeas@ie=
ee.org> wrote:
>I see different things in the original code that I did not quite grasp
>in
>the first read. It might be good if you went through a more detailed
>description of the different things that you want and how you believe
>can
>be implemented. That would possibly clarify points that others (i.e.
>me)
>might have missed.
>
>For starters, it seems from a later comment that you don't want to
>provide
>syntactic sugar around a single return type that mimics 'one_of<A,B,C>'
>but
>rather have a control flow structure in which the callee will return to
>different addresses depending on what return was hit. In the first
>example
>you want 'main' to look something like (pseudo code):
>
>int main() {
> int i;
> std::cin >> i;
> [[uninitialized]] union { int i; float f } __return;
> foo(&__return, i);
>return_int:
> // buffer holds an 'int'
> bar(__return.i);
> return 0;
>return_float:
> // buffer holds a 'float'
> bar(__return.f);
> return 0;
>}
>
>Where it is 'foo' who makes the decision as of which label to return to
>(multiple return addresses passed to 'foo', foo jumps back to one of
>them).
>
>void foo(union { int i; float f; } *__return; int i) {
> if (i > 10) {
> new (__return->i) int(i);
> return return_int;
> } else {
> new (__return->f) float(i);
> return return_float;
> }
>}
>
>I am not sure if this construct would be reduced to being used directly
>as
>part of an immediate function call or "virtual switch" or if you want
>to
>support other use cases. If other cases need to be supported, the code
>above can turn into a fair amount of different code paths each of which
>might amount to as much as the remainder of the function. Consider:
>
>void f(int i) {
> auto a =3D foo(i);
> auto b =3D foo(i + 5);
> auto c =3D foo(i - 5);
> // Some code here that uses a, b, c
>}
>
>That "simple" piece of code has 8 different possible combinations of
>types
>for (a,b,c), which means that "// some code here" behaves as a template
>that is specialized for the 8 different cases, possibly contributing to
>a
>fair amount of code bloat. I am not saying that if that is what your
>program needs there are better alternatives, but it becomes a bit less
>obvious to reason about code. I don't love the idea of 'auto'
>everywhere as
>it hides the actual type, but this goes one step beyond, you cannot
>reason
>about the type even if you see the declaration of the function!
>
>If only the immediate function call is to be supported this can be
>trivially written in C++14 (I believe, I am still writing C++03, bear
>with
>me):
>
>template <typename T>
>void foo(int i, T continuation) {
> if (i > 10) continuation(i);
> else continuation(static_cast<float>(i));
>}
>int main() {
> int i;
> std::cin >> i;
> foo(i, [](auto x) { bar(x); });
>}
>
>Now, a completely different feature is mentioned in the original
>message:
>
> virtual switch(auto a =3D foo(i)) {
> virtual case B*: std::cout<<"B!"<<std::endl; break;
> virtual case C*: std::cout<<"C!"<<std::endl; break;
>
>
>This is hiding an unrelated feature, the compiler matching *dynamic*
>types.
>I consider this feature almost orthogonal to the other in the sense
>that
>you could do the same thing with 'A* foo(int)' (single, simple,
>currrent
>form of return type) although it complements the other feature in
>enriching
>the possibilities. The code in that switch (assuming single return
>type),
>could be simply translated to:
>
>auto a =3D foo(i);
> if (dynamic_cast<B*>(a)) { std::cout << "B!\n"; }
>else if (dynamic_cast<C*>(a)) { std::cout << "C!\n"; }
>
>And without that assumption (i.e. considering the set of return types
>as in
>the first part) that would be what the 'return_A_ptr' label would have
>to
>look like. Note that this requires that the compiler sees the
>definition of
>the types 'A', 'B' and 'C' to be able to perform the 'dynamic_cast'.
>Except
>that both features don't quite mix cleanly. Consider this modified
>'foo'
>version:
>
><A*, B*, int> foo (int i)
>{
> if (i =3D=3D 1) return<A*> new B;
> if (i =3D=3D 2) return<A*> new C;
> if (i =3D=3D 3) return<B*> new B;
> return<int> 0;
>};
>
>virtual switch(auto a =3D foo(i))
> {
> virtual case B*: std::cout<<"B!"<<std::endl; break;
> virtual case C*: std::cout<<"C!"<<std::endl; break;
>
>When should the 'virtual case B*' be hit? When the function returns
>'B*' or
>also when it returns 'A*' which may be really a 'B*'? At any rate the
>definition of the types would need to be seen here. Note that in the
>case
>of the function call, the compiler does not need to have the definition
>of
>the types:
>
>void bar(X*);
>void bar(Y*);
>{X*,Y*} foo();
>bar(foo()); // Compiler only needs a declaration of X and Y for
>this
>
>Personally I don't recall having needed this. I have needed to switch
>on a
>runtime value to trigger different code paths, but I have solve that by
>reading the value and then jumping to different functions (sometimes a
>template), with a solution not that different from 'foo(i, [](auto x) {
>bar(x); })' with the exception that in my case 'foo' was manually
>inlined
>(or the call to bar was explicit in 'foo', not an argument to the
>function.
>
>I would suggest that you think about the different features you want
>(the
>two mentioned, any other that I might have missed), the problems that
>each
>one of them solves and how much simpler the solution with the new
>feature
>would be compared with the current state of the language. If you come
>up
>with motivating examples the exact details and issues that you might
>have
>missed can be further discussed.
>
>David
>
>
>On Wed, Aug 13, 2014 at 4:39 AM, Klaim - Jo=C3=ABl Lamotte
><mjklaim@gmail.com>
>wrote:
>
>> If I =E2=80=8Bunderstand correctly, such a function using the proposed r=
eturn
>> system would
>> - only be usable if inline;
>> - deduce the return type at compile time;
>>
>> I can see some use but not a generalisation.
>> The interesting idea is to rely on compile-time instead of runtime
>like
>> for exceptions.
>>
>> However, I would like to see examples of code that would definitely
>> benefit to have such a feature.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google
>Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
--=20
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--=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/.
.
Author: "Ryan P. Nicholl" <r.p.nicholl@gmail.com>
Date: Wed, 13 Aug 2014 11:13:25 -0400
Raw View
No, the return type is determined at runtime. That is the entire purpose, t=
o work where templates will not.
<int, float> is a concrete return type and would require a new specialized =
ABI for calling such functions.
On August 13, 2014 4:39:41 AM EDT, "Klaim - Jo=C3=ABl Lamotte" <mjklaim@gma=
il.com> wrote:
>If I =E2=80=8Bunderstand correctly, such a function using the proposed ret=
urn
>system would
> - only be usable if inline;
> - deduce the return type at compile time;
>
>I can see some use but not a generalisation.
>The interesting idea is to rely on compile-time instead of runtime like
>for
>exceptions.
>
>However, I would like to see examples of code that would definitely
>benefit
>to have such a feature.
--=20
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--=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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 13 Aug 2014 08:42:14 -0700
Raw View
On Tuesday 12 August 2014 23:59:58 Ryan P. Nicholl wrote:
> And no, I'm not describing that. Again another person doesn't read the
> original message. You can not do std::string::string(boost::variant).
I read your original message and I still think this can be accomplished with a
library solution.
I have probably missed something in the original message that you think cannot
be accomplished with just a library. So please bear with me (us) and explain
it again.
> Other than that, my response to your logic is this:
> C++ should not include generic typing, because you can include a library
> which emulates a i386 PC in C++, boot linux on that, then run java in that
> which supports generic typing.
That's not a good argument. If you want to convince me (us) that a non-library
solution is required, you need to explain why a library solution won't work.
> A language feature would provide a standard interface and would also work
> with old code (like std::string.) It would be much faster too.
I don't understand what you mean.
Why wouldn't one_of<std::string, boost::variant, int, QVariant> not work?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: r.p.nicholl@gmail.com
Date: Wed, 13 Aug 2014 10:10:48 -0700 (PDT)
Raw View
------=_Part_223_1346030359.1407949848927
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I don't believe you can pass templates as arguments to functions. Correct=
=20
me if I'm wrong, but I believe this also applies to lambdas. Also, lambdas=
=20
must have a concrete return type.
After some consideration, I revised the syntax a little:
<std::vector<uint8_t> result, int errorno> to_binary(my_class const & o)
{
....
}
int main()
{
...
virtual switch to_binary(my_class)
{
case result:
{
some_file << result;
}
case errorno:
{
std::cerr << ...;
}=20
}
}
Syntax:
Returns:
< type [name] ... >
e.g.
<int, int>
// case 0 and case 1
<int i, int i2>
// case 0, case 1, case i:, case i2:
<int i, float f, int i2>
// case 0, case 1, case 3, case float, case i, case f, case i2=20
Virtual switch call:
virtual switch *func_name*(*parameters*)
{
*cases*
}
*cases* is one or more *case*. Syntax of a *case* is one of:
Basic:
case *name* *[*(*scoped_name*)*]*: { *body* }
: uns for the return called "name", you can redefine the name in your scope=
=20
with the optional "scoped name" parameter.
case *type* (*name*) { *body* }
: Runs for the type *type*. It is called *name* in your scope.
virtual case type (name) { body }
: Runs for any polymorphic return which can be cast to type.
default { *body* }
: Runs for anything.
virtual case type*[*, *matches]*... (*name*) { body }
: Runs for any of matches which are able to be dynamically cast to type.
(So e.g.)
<A*, B*, C*> foo ()
{
....
}
int main()
{
virtual switch foo()
{
virtual case B*, 0, C* (b)
{
// This only runs when B* is cast from A* or C*, but not the B* part.
}
}
}
And:
break;
: Exits early.
continue;
: Exits current handler, but attempts the rest of the handlers in the chain=
=20
also if they could be applicable (ie, virtual etc)
On Wednesday, August 13, 2014 10:15:15 AM UTC-4, David Rodr=C3=ADguez Ibeas=
=20
wrote:
>
> I see different things in the original code that I did not quite grasp in=
=20
> the first read. It might be good if you went through a more detailed=20
> description of the different things that you want and how you believe can=
=20
> be implemented. That would possibly clarify points that others (i.e. me)=
=20
> might have missed.
>
> For starters, it seems from a later comment that you don't want to provid=
e=20
> syntactic sugar around a single return type that mimics 'one_of<A,B,C>' b=
ut=20
> rather have a control flow structure in which the callee will return to=
=20
> different addresses depending on what return was hit. In the first exampl=
e=20
> you want 'main' to look something like (pseudo code):
>
> int main() {
> int i;
> std::cin >> i;
> [[uninitialized]] union { int i; float f } __return;
> foo(&__return, i);
> return_int:
> // buffer holds an 'int'
> bar(__return.i);
> return 0;
> return_float:
> // buffer holds a 'float'
> bar(__return.f);
> return 0;
> }
>
> Where it is 'foo' who makes the decision as of which label to return to=
=20
> (multiple return addresses passed to 'foo', foo jumps back to one of them=
).=20
>
> void foo(union { int i; float f; } *__return; int i) {
> if (i > 10) {
> new (__return->i) int(i);
> return return_int;
> } else {
> new (__return->f) float(i);
> return return_float;
> }
> }
>
> I am not sure if this construct would be reduced to being used directly a=
s=20
> part of an immediate function call or "virtual switch" or if you want to=
=20
> support other use cases. If other cases need to be supported, the code=20
> above can turn into a fair amount of different code paths each of which=
=20
> might amount to as much as the remainder of the function. Consider:
>
> void f(int i) {
> auto a =3D foo(i);
> auto b =3D foo(i + 5);
> auto c =3D foo(i - 5);
> // Some code here that uses a, b, c
> }
>
> That "simple" piece of code has 8 different possible combinations of type=
s=20
> for (a,b,c), which means that "// some code here" behaves as a template=
=20
> that is specialized for the 8 different cases, possibly contributing to a=
=20
> fair amount of code bloat. I am not saying that if that is what your=20
> program needs there are better alternatives, but it becomes a bit less=20
> obvious to reason about code. I don't love the idea of 'auto' everywhere =
as=20
> it hides the actual type, but this goes one step beyond, you cannot reaso=
n=20
> about the type even if you see the declaration of the function!
>
> If only the immediate function call is to be supported this can be=20
> trivially written in C++14 (I believe, I am still writing C++03, bear wit=
h=20
> me):
>
> template <typename T>
> void foo(int i, T continuation) {
> if (i > 10) continuation(i);
> else continuation(static_cast<float>(i));
> }
> int main() {
> int i;
> std::cin >> i;
> foo(i, [](auto x) { bar(x); });
> }
>
> Now, a completely different feature is mentioned in the original message:
>
> virtual switch(auto a =3D foo(i)) {
> virtual case B*: std::cout<<"B!"<<std::endl; break;
> virtual case C*: std::cout<<"C!"<<std::endl; break;
>
>
> This is hiding an unrelated feature, the compiler matching *dynamic*=20
> types. I consider this feature almost orthogonal to the other in the sens=
e=20
> that you could do the same thing with 'A* foo(int)' (single, simple,=20
> currrent form of return type) although it complements the other feature i=
n=20
> enriching the possibilities. The code in that switch (assuming single=20
> return type), could be simply translated to:
>
> auto a =3D foo(i);
> if (dynamic_cast<B*>(a)) { std::cout << "B!\n"; }
> else if (dynamic_cast<C*>(a)) { std::cout << "C!\n"; }
>
> And without that assumption (i.e. considering the set of return types as=
=20
> in the first part) that would be what the 'return_A_ptr' label would have=
=20
> to look like. Note that this requires that the compiler sees the definiti=
on=20
> of the types 'A', 'B' and 'C' to be able to perform the 'dynamic_cast'.=
=20
> Except that both features don't quite mix cleanly. Consider this modified=
=20
> 'foo' version:
>
> <A*, B*, int> foo (int i)
> {
> if (i =3D=3D 1) return<A*> new B;
> if (i =3D=3D 2) return<A*> new C;
> if (i =3D=3D 3) return<B*> new B;
> return<int> 0;
> };
>
> virtual switch(auto a =3D foo(i))
> {
> virtual case B*: std::cout<<"B!"<<std::endl; break;
> virtual case C*: std::cout<<"C!"<<std::endl; break;
>
> When should the 'virtual case B*' be hit? When the function returns 'B*'=
=20
> or also when it returns 'A*' which may be really a 'B*'? At any rate the=
=20
> definition of the types would need to be seen here. Note that in the case=
=20
> of the function call, the compiler does not need to have the definition o=
f=20
> the types:
>
> void bar(X*);
> void bar(Y*);
> {X*,Y*} foo();
> bar(foo()); // Compiler only needs a declaration of X and Y for th=
is
>
> Personally I don't recall having needed this. I have needed to switch on =
a=20
> runtime value to trigger different code paths, but I have solve that by=
=20
> reading the value and then jumping to different functions (sometimes a=20
> template), with a solution not that different from 'foo(i, [](auto x) {=
=20
> bar(x); })' with the exception that in my case 'foo' was manually inlined=
=20
> (or the call to bar was explicit in 'foo', not an argument to the functio=
n.
>
> I would suggest that you think about the different features you want (the=
=20
> two mentioned, any other that I might have missed), the problems that eac=
h=20
> one of them solves and how much simpler the solution with the new feature=
=20
> would be compared with the current state of the language. If you come up=
=20
> with motivating examples the exact details and issues that you might have=
=20
> missed can be further discussed.
>
> David
>
>
> On Wed, Aug 13, 2014 at 4:39 AM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail.=
com=20
> <javascript:>> wrote:
>
>> If I =E2=80=8Bunderstand correctly, such a function using the proposed r=
eturn=20
>> system would=20
>> - only be usable if inline;
>> - deduce the return type at compile time;
>>
>> I can see some use but not a generalisation.
>> The interesting idea is to rely on compile-time instead of runtime like=
=20
>> for exceptions.
>>
>> However, I would like to see examples of code that would definitely=20
>> benefit to have such a feature.
>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_223_1346030359.1407949848927
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't believe you can pass templates as arguments to fun=
ctions. Correct me if I'm wrong, but I believe this also applies to lambdas=
.. Also, lambdas must have a concrete return type.<br><br>After some conside=
ration, I revised the syntax a little:<br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><std::vector</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify"><uint8_t></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> result, int errorno> to_binary=
(my_class const & o)<br>{<br>...<br>}<br><br>int main()<br>{<br> =
....<br> virtual switch to_binary(my_class)<br> {<br> &nbs=
p; case result:<br> {<br> some_file <&l=
t; result;<br> }<br><br> case errorno:<br> =
{<br> std::cerr << ...;<br> }=
<br>}<br>}<br></span></div></code></div><br>Syntax:<br><br>Returns:<br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">< type [name=
] ... ><br>e.g.<br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify"><int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">, </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #008;" class=3D"styled-by-prettify">></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>// case =
0 and case 1<br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify"><int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">i</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">, </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">i2</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>// case 0, case 1, case i:, case i2:<br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify"><int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">i</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">, </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">float</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">f</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">, </span><span style=3D"color: #606;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">i2</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>// case 0, case 1, case 3, =
case float, case i, case f, case i2 <br></span></div></code></div><br>Virtu=
al switch call:<br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">switc=
h</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
i><span style=3D"color: #000;" class=3D"styled-by-prettify">func_name</span=
></i><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><i><=
span style=3D"color: #000;" class=3D"styled-by-prettify">parameters</span><=
/i><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><i><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cases</span></i><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br><i>cases</i> is=
one or more <i>case</i>. Syntax of a <i>case</i> is one of:<i><br></i>Basi=
c:<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">case</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><i><=
span style=3D"color: #000;" class=3D"styled-by-prettify">name</span></i><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><i><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[</span></i><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><i><span style=3D"color=
: #000;" class=3D"styled-by-prettify">scoped_name</span></i><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><i><span style=3D"color:=
#660;" class=3D"styled-by-prettify">]</span></i><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: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><i><span style=3D"color: #000;" class=3D"styled-by-prettify">=
body</span></i><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div>: uns for the return called "name", you can redefine the name in =
your scope with the optional "scoped name" parameter.<br><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><i><span style=3D"color: #=
000;" class=3D"styled-by-prettify">type</span></i><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><i><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">name</span></i><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><i>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">body</span></i><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span></div></code></div>: Runs =
for the type <i>type</i>. It is called <i>name</i> in your scope.<br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> type </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">name</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bo=
dy </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div>: Runs for any polymorphic return which can be cast to type.<=
br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">default</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><i><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">body</span></i><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span></div></code></div>: Runs for anything.<br>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wo=
rd-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> type</span><i><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span></i><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><i><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">matches</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span></i><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><i><span style=3D"color: #000;" class=3D"styled-by-prettify">nam=
e</span></i><span style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> body </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span></div></code></div>: Runs for any =
of matches which are able to be dynamically cast to type.<br>(So e.g.)<br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify"><A</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">*, </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">B</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">*, </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">C</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">*</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> foo ()<br>{<br>...<br>}<br><br>int main()<br>{<br> virtual=
switch foo()<br> {<br> virtual case B*, 0, C* (b)<br>&n=
bsp; {<br> // This only runs when B* is cast fro=
m A* or C*, but not the B* part.<br> }<br> }<br>}<br></s=
pan></div></code></div><br>And:<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">break</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span></div></code></div>: Exits early.<br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">continue</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></div></code></div>: E=
xits current handler, but attempts the rest of the handlers in the chain al=
so if they could be applicable (ie, virtual etc)<br><br>On Wednesday, Augus=
t 13, 2014 10:15:15 AM UTC-4, David Rodr=C3=ADguez Ibeas wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I see different things in=
the original code that I did not quite grasp in the first read. It might b=
e good if you went through a more detailed description of the different thi=
ngs that you want and how you believe can be implemented. That would possib=
ly clarify points that others (i.e. me) might have missed.<br>
<br>For starters, it seems from a later comment that you don't want to prov=
ide syntactic sugar around a single return type that mimics 'one_of<A,B,=
C>' but rather have a control flow structure in which the callee will re=
turn to different addresses depending on what return was hit. In the first =
example you want 'main' to look something like (pseudo code):<br>
<br><div>int main() {<br> int i;<br> std::cin >&=
gt; i;<br> [[uninitialized]] union { int i; float f } __return;=
<br> foo(&__return, i);<br>return_int:<br> // b=
uffer holds an 'int'<br> bar(__return.i);<br>
return 0;<br>return_float:<br> // buffer holds a '=
float'<br> bar(__return.f);<br> return 0;<br>}<br><=
br>Where it is 'foo' who makes the decision as of which label to return to =
(multiple return addresses passed to 'foo', foo jumps back to one of them).=
<br>
<br>void foo(union { int i; float f; } *__return; int i) {<br> =
if (i > 10) {<br> new (__return->i) int(i=
);<br> return return_int;<br> } els=
e {<div> new (__return->f) float(i);<br> =
; return return_float;<br>
}<br>}</div><br>I am not sure if this construct would be redu=
ced to being used directly as part of an immediate function call or "virtua=
l switch" or if you want to support other use cases. If other cases need to=
be supported, the code above can turn into a fair amount of different code=
paths each of which might amount to as much as the remainder of the functi=
on. Consider:<br>
<br>void f(int i) {<br> auto a =3D foo(i);<br> au=
to b =3D foo(i + 5);<br> auto c =3D foo(i - 5);<br> &nbs=
p; // Some code here that uses a, b, c<br>}<br><br>That "simple" piece of c=
ode has 8 different possible combinations of types for (a,b,c), which means=
that "// some code here" behaves as a template that is specialized for the=
8 different cases, possibly contributing to a fair amount of code bloat. I=
am not saying that if that is what your program needs there are better alt=
ernatives, but it becomes a bit less obvious to reason about code. I don't =
love the idea of 'auto' everywhere as it hides the actual type, but this go=
es one step beyond, you cannot reason about the type even if you see the de=
claration of the function!</div>
<div><br></div><div>If only the immediate function call is to be supported =
this can be trivially written in C++14 (I believe, I am still writing C++03=
, bear with me):<br><br>template <typename T><br>void foo(int i, T co=
ntinuation) {<br>
if (i > 10) continuation(i);<br> else continuat=
ion(static_cast<<wbr>float>(i));<br>}<br>int main() {<br>  =
;int i;<br> std::cin >> i;<br> foo(i, [](auto=
x) { bar(x); });<br>}<br><br>Now, a completely different feature is mentio=
ned in the original message:<br>
<br><div style=3D"background-color:rgb(250,250,250)"><font color=3D"#666600=
" face=3D"monospace" size=3D"1"> virtual switch(auto a =3D foo(i)) {<=
/font></div><div style=3D"background-color:rgb(250,250,250)"><font color=3D=
"#666600" face=3D"monospace" size=3D"1"> virtual case B*: =
;</font><span style=3D"color:rgb(102,102,0);font-family:monospace;font-size=
:x-small">std::cout<<"B!"<<std::<wbr>endl;</span><span style=3D=
"color:rgb(102,102,0);font-family:monospace;font-size:x-small"> break;=
</span></div>
<div style=3D"background-color:rgb(250,250,250)"><font color=3D"#666600" fa=
ce=3D"monospace" size=3D"1"> virtual case C*:</font><span styl=
e=3D"color:rgb(102,102,0);font-family:monospace;font-size:x-small"> st=
d::cout<<"C!"<<std::<wbr>endl; </span><span style=3D"color=
:rgb(102,102,0);font-family:monospace;font-size:x-small">break;</span></div=
>
<div style=3D"background-color:rgb(250,250,250)"><br></div><div><span style=
=3D"background-color:rgb(255,255,255)"><br>This is hiding an unrelated feat=
ure, the compiler matching *dynamic* types. I consider this feature almost =
orthogonal to the other in the sense that you could do the same thing with =
'A* foo(int)' (single, simple, currrent form of return type) although it co=
mplements the other feature in enriching the possibilities. The code =
in that switch (assuming single return type), could be simply translated to=
:<br>
<br>auto a =3D foo(i);<br> if (dynamic_cast<B*=
>(a)) { std::cout << "B!\n"; }<br>else if (dynamic_cast<C*>(=
a)) { std::cout << "C!\n"; }<br><br>And without that assumption (i.e.=
considering the set of return types as in the first part) that would be wh=
at the 'return_A_ptr' label would have to look like. Note that this require=
s that the compiler sees the definition of the types 'A', 'B' and 'C' to be=
able to perform the 'dynamic_cast'. Except that both features don't quite =
mix cleanly. Consider this modified 'foo' version:<br>
<br><div><A*, B*, int> foo (int i)</div><div>{</div><div> if (i=
=3D=3D 1) return<A*> new B;</div><div> if (i =3D=3D 2) return&=
lt;A*> new C;<br> if (i =3D=3D 3) return<B*> new B;</div><di=
v> return<int> 0;</div>
<div>};<br><br><div>virtual switch(auto a =3D foo(i))</div><div> {</d=
iv><div> virtual case B*: std::cout<&l=
t;"B!"<<std::endl; break;</div><div>  =
; virtual case C*: std::cout<<"C!"<<std::e=
ndl; break;<br>
<br>When should the 'virtual case B*' be hit? When the function returns 'B*=
' or also when it returns 'A*' which may be really a 'B*'? At any rate the =
definition of the types would need to be seen here. Note that in the case o=
f the function call, the compiler does not need to have the definition of t=
he types:<br>
<br>void bar(X*);<br>void bar(Y*);<br>{X*,Y*} foo();<br>bar(foo()); =
// Compiler only needs a declaration of X and Y for thi=
s<br><br>Personally I don't recall having needed this. I have needed to swi=
tch on a runtime value to trigger different code paths, but I have solve th=
at by reading the value and then jumping to different functions (sometimes =
a template), with a solution not that different from 'foo(i, [](auto x) { b=
ar(x); })' with the exception that in my case 'foo' was manually inlined (o=
r the call to bar was explicit in 'foo', not an argument to the function.<b=
r>
<br>I would suggest that you think about the different features you want (t=
he two mentioned, any other that I might have missed), the problems that ea=
ch one of them solves and how much simpler the solution with the new featur=
e would be compared with the current state of the language. If you co=
me up with motivating examples the exact details and issues that you might =
have missed can be further discussed.<br>
<br>David</div></div></span></div></div></div><div><br><br><div class=3D"gm=
ail_quote">On Wed, Aug 13, 2014 at 4:39 AM, Klaim - Jo=C3=ABl Lamotte <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"uMoefGArtNkJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">mjk...@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">If I =E2=80=8Bundersta=
nd correctly, such a function using the proposed return system would <=
div> - only be usable if inline;</div>
<div> - deduce the return type at compile time;</div><div><br></div><d=
iv>I can see some use but not a generalisation.</div>
<div>The interesting idea is to rely on compile-time instead of runtime lik=
e for exceptions.</div><div><br></div><div>However, I would like to see exa=
mples of code that would definitely benefit to have such a feature.</div>
<div><br></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
uMoefGArtNkJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"uMoefGArtNkJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_223_1346030359.1407949848927--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 25 Sep 2014 18:39:40 -0400
Raw View
(Sorry, I'm still trying to catch up after not having list access for a
while... Also, disclaimer, this is based on my understanding of what the
OP requested...)
On 2014-08-13 11:42, Thiago Macieira wrote:
> On Tuesday 12 August 2014 23:59:58 Ryan P. Nicholl wrote:
>> And no, I'm not describing that. Again another person doesn't read the
>> original message. You can not do std::string::string(boost::variant).
>
> I read your original message and I still think this can be accomplished with a
> library solution.
void foo(int);
void foo(float);
<int, float> bar(int i);
int main()
{
foo(bar(rand()); // call overload based on return type
}
You could *do* this with a library-only solution, but it would require
writing out a switch statement to call the appropriate overload, whereas
what Ryan is proposing, the compiler would do that for you. This (and
the syntax sugar for a variant-like return type) seems to be the main
value-add over a library solution. The 'virtual switch' is less
interesting because you could implement it using if() and a library
solution.
Actually... in that sense, it might be better to reduce at least the
initial proposal to a library 'fixed type set' variant type and the
ability to do something like:
void foo(int);
void foo(float);
std::one_of<int, float> bar(int i);
// Compiler expands this to code to call the appropriate overload of
// 'foo' based on the value type returned by 'bar'
foo(bar(rand());
I could see requiring some additional syntax to make that expansion happen.
I'm not sure if I like it or not, but it's interesting...
>> A language feature would provide a standard interface and would also work
>> with old code (like std::string.) It would be much faster too.
>
> Why wouldn't one_of<std::string, boost::variant, int, QVariant> not work?
Again, it's not so much the return value that's the problem, it's
passing that one_of to a ctor (belong to code that you can't practically
modify, for whatever reason, e.g. because it is an STL class) that has
overloads taking all of the possible types of the one_of.
IOW:
<std::string, std::string&&> foo();
auto s = std::string{foo()};
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Ryan P. Nicholl" <r.p.nicholl@gmail.com>
Date: Thu, 25 Sep 2014 21:09:51 -0400
Raw View
My other note is that this could give a standard ABI for multi outcome code... consider also the possibility of code like:
<void main, void child, int errnum> fork();
It could do this in a way that makes more sense...
Thank you,
Ryan P. Nicholl
C++ Developer
(678)-358 7765
r.p.nicholl@gmail.com
--
---
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/.
.