Topic: Imperative Template Grammar
Author: Brian Anderle <whattayabrian@gmail.com>
Date: Mon, 29 Jul 2013 14:50:20 -0700 (PDT)
Raw View
------=_Part_1994_33092233.1375134620574
Content-Type: text/plain; charset=ISO-8859-1
Templates are confusing. It seems to me that there are three main
divisions of C++ engineers based on template familiarity.
1. Will use templated classes supplied but will not attempt to create their
own.
2. Would be comfortable implementing a generalized container or algorithm.
3. Metaprogramming: implementing type lists, expression trees, and the
whole shebang.
I would wager based on personal experience that most professional C++
engineers fall into group 2. There are various arguments as to "why", but
I believe the answer is clear.
C++ engineers are taught a language that is *imperative* and *iterative*(mostly).
Template metaprogramming is *declarative *and *recursive *(mostly).
This creates a huge schism between thought patterns; one that is very
difficult to overcome. Very little of what they've been learning carries
over into this new land.
Let's imagine one of these group 2 programmers wants to create a templated
allocator. For their purposes, they want this allocator to check the
sizeof(T), and if that size is under some value, use a memory pool,
otherwise just use the free store. This is totally trivial to implement at
runtime, but what if they wanted to do so at compile time? Well, a naive
runtime implementation might look something like this:
const unsigned MEMORY_CUTOFF = 32;
template<class T>
class MyAllocator
{
MyAllocator()
: _usePool(false)
{
if(sizeof(T) <= MEMORY_CUTOFF)
{
_pool.Initialize(/*...*/);
_usePool = true;
}
}
T * Allocate()
{
if(_usePool)
{
return _pool.Allocate();
}
else
{
return new T;
}
}
bool _usePool;
MyMemoryPool<T> _pool;
};
Of course a number of problems immediately arise, perhaps the most severe
of which is the fact that between the pool path and the non-pool path, the
client contract changes. The client is responsible for freeing the memory
only in the case where the pool is unused. But I ask that for the sake of
the example, you ignore these things for now. Contrived examples are
contrived.
If I wanted to convert this to a compile time decision (which I should be
able to do since all the necessary information is known at compile time), I
would have no idea how. I know there must be a way, but I can't logically
inch my way there like I could runtime C++ problems. My toolset does not
apply here. I know with the super generic factorial example for
metaprogramming that you see everywhere, you can specialize for specific
values of T, but the factorial was actually templated from an integral
type, whereas MyAllocator has a general T, and I'm testing against
sizeof(T). But even if I could specialize somehow, I would have no idea
how to do that based on a const value like MEMORY_CUTOFF.
So let's see an example of the proposal proper:
template<class T>
class MyAllocator
{
MyAllocator()
{
compile_if(sizeof(T) <= MEMORY_CUTOFF)
{$
_pool.Initialize(...);
_usePool = true;
$}
}
T * Allocate()
{
compile_if(sizeof(T) <= MEMORY_CUTOFF)
{$
return _pool.Allocate();
$}
compile_else
{$
return new T;
$}
}
compile_if(sizeof(T) <= MEMORY_CUTOFF)
{$
MyMemoryPool<T> _pool;
$}
};
Please pretend the brace-dollar-sign scopes are something much prettier
that also don't require you to escape any characters within the scope.
You could also imagine that you don't want to retype out that condition
each time since that's error-prone.
compile_bool USE_POOL = sizeof(T) <= MEMORY_CUTOFF
And of course that brings up a host of other questions about whether or not
USE_POOL could ever be mutable and if so, what is the order of code
generation over the class, etc etc, that would have to be answered, but
that's outside the scope of this post.
And you could imagine having fine-tuned control over errors and warnings in
your class.
compile_if(implements(T::begin()) && implements(T::end()))
{$
...
$}
compile_else
{$
compile_error("Type " + str(T) + " does not implement both begin() and
end()")
$}
(Of course Concepts is also doing lots of good work to make this problem
better as well.)
So, in a nutshell, I want macros, except they can treat T like a type
instead of a token, and are run for each instantiation of the template.
Note that there's no reason this couldn't be used outside of templates,
although the effect would be largely the same as macros.
*It is not that this lets us to do something we could not before, but
rather lets us do it in a way that mirrors the way we are used to coding
and should help bridge the gap to getting more programmers, myself
included, into group 3.*
*
*
As an aside, I imagine this grammar would be minimalist on the same order
of magnitude as something like HLSL.
Thoughts?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1994_33092233.1375134620574
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Templates are confusing. It seems to me that there are three mai=
n divisions of C++ engineers based on template familiarity.<br></div><div><=
br></div><div>1. Will use templated classes supplied but will not attempt t=
o create their own.</div><div>2. Would be comfortable implementing a genera=
lized container or algorithm.</div><div>3. Metaprogramming: implementing ty=
pe lists, expression trees, and the whole shebang.</div><div><br></div><div=
>I would wager based on personal experience that most professional C++ engi=
neers fall into group 2. There are various arguments as to "why", but=
I believe the answer is clear.</div><div><br></div><div>C++ engineers are =
taught a language that is <b>imperative</b> and <b>iterative</b> (mostly).<=
/div><div>Template metaprogramming is <b>declarative </b>and <b>recursive <=
/b>(mostly).</div><div><br></div><div>This creates a huge schism between th=
ought patterns; one that is very difficult to overcome. Very little o=
f what they've been learning carries over into this new land.</div><div><br=
></div><div>Let's imagine one of these group 2 programmers wants to create =
a templated allocator. For their purposes, they want this allocator t=
o check the sizeof(T), and if that size is under some value, use a memory p=
ool, otherwise just use the free store. This is totally trivial to im=
plement at runtime, but what if they wanted to do so at compile time?  =
;Well, a naive runtime implementation might look something like this:</div>=
<div><br></div><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">unsigned</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> MEMORY_CUTOFF </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">32</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=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">class</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">MyAllocator</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></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: #606;" class=3D"styled-by-=
prettify">MyAllocator</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"=
> _usePool</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">false</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"=
color: #000;" class=3D"styled-by-prettify"><br> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">T</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"><=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> MEMORY_CU=
TOFF</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
_pool</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">.</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Initial=
ize</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">/*...*/</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> _us=
ePool </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">true</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> </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><br><br> T </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Allocate</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=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_usePool=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><s=
pan 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> &nb=
sp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">return<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _pool</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Allocate</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #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> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">else</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> </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">return</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">new</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> T</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> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </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><br><br> </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> _usePool</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">My=
MemoryPool</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> _pool</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">};</span></div></code></div><br><div>Of =
course a number of problems immediately arise, perhaps the most severe of w=
hich is the fact that between the pool path and the non-pool path, the clie=
nt contract changes. The client is responsible for freeing the memory=
only in the case where the pool is unused. But I ask that for the sa=
ke of the example, you ignore these things for now. Contrived example=
s are contrived.<br></div><div><br></div><div>If I wanted to convert this t=
o a compile time decision (which I should be able to do since all the neces=
sary information is known at compile time), I would have no idea how.  =
;I know there must be a way, but I can't logically inch my way there like I=
could runtime C++ problems. My toolset does not apply here. I =
know with the super generic factorial example for metaprogramming that you =
see everywhere, you can specialize for specific values of T, but the factor=
ial was actually templated from an integral type, whereas MyAllocator has a=
general T, and I'm testing against sizeof(T). But even if I could sp=
ecialize somehow, I would have no idea how to do that based on a const valu=
e like MEMORY_CUTOFF.</div><div><br></div><div>So let's see an example of t=
he proposal proper:</div><div><br></div><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">template=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-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-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">MyAllocator</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">MyAllocator</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>&nb=
sp; compile_if</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>sizeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><spa=
n 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"><=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> MEMORY_CUTOFF</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;" c=
lass=3D"styled-by-prettify">$<br> _pool</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Initialize</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(...);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> _usePool </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">true</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=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><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br><br> T </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Allocate</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><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
compile_if</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">si=
zeof</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> MEMORY_CUTOFF</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><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">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> _pool</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Allocate</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> $</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> compile_else<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">return</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> $</span><span style=3D"color: #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"style=
d-by-prettify"><br><br><br> compile_if</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">T</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"><=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> MEMORY_CUTOFF</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">$<br> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">MyMemoryPool</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> _pool</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-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><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">};</span></div></code></div><div><br></div><div><br></div><div>Please =
pretend the brace-dollar-sign scopes are something much prettier that also =
don't require you to escape any characters within the scope.</div><div><br>=
</div><div>You could also imagine that you don't want to retype out that co=
ndition each time since that's error-prone.</div><div><br></div><div><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border:=
1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">compile_bool USE_POOL </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">sizeof</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">T</span><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"><=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> MEMORY_CUTOFF</span></div=
></code></div><br></div><div>And of course that brings up a host of other q=
uestions about whether or not USE_POOL could ever be mutable and if so, wha=
t is the order of code generation over the class, etc etc, that would have =
to be answered, but that's outside the scope of this post.<br></div><div><b=
r></div><div>And you could imagine having fine-tuned control over errors an=
d warnings in your class.</div><div><br></div><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">co=
mpile_if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">implements<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">begin</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&&</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">implements</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">end</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">()))</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"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: #66=
0;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" cla=
ss=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-b=
y-prettify"><br>compile_else<br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">$<br> compile_error</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify">"Type "</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-prettify"> =
str</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #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"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">" does not implement both begin() and end()"</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>$</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span></div></code></div><div><br></di=
v><div>(Of course Concepts is also doing lots of good work to make this pro=
blem better as well.)</div><div><br></div><div>So, in a nutshell, I want ma=
cros, except they can treat T like a type instead of a token, and are run f=
or each instantiation of the template.</div><div><br></div><div>Note that t=
here's no reason this couldn't be used outside of templates, although the e=
ffect would be largely the same as macros.</div><div><br></div><div><b>It i=
s not that this lets us to do something we could not before, but rather let=
s us do it in a way that mirrors the way we are used to coding and should h=
elp bridge the gap to getting more programmers, myself included, into group=
3.</b></div><div><b><br></b></div><div>As an aside, I imagine this grammar=
would be minimalist on the same order of magnitude as something like HLSL.=
</div><div><br></div><div>Thoughts?</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1994_33092233.1375134620574--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 29 Jul 2013 17:01:40 -0500
Raw View
--089e015372747b8eb004e2ada53c
Content-Type: text/plain; charset=ISO-8859-1
On 29 July 2013 16:50, Brian Anderle <whattayabrian@gmail.com> wrote:
>
>
> So let's see an example of the proposal proper:
>
> template<class T>
> class MyAllocator
> {
> MyAllocator()
> {
> compile_if(sizeof(T) <= MEMORY_CUTOFF)
> {$
> _pool.Initialize(...);
> _usePool = true;
> $}
> }
>
>
> T * Allocate()
> {
> compile_if(sizeof(T) <= MEMORY_CUTOFF)
> {$
> return _pool.Allocate();
> $}
> compile_else
> {$
> return new T;
> $}
> }
>
>
> compile_if(sizeof(T) <= MEMORY_CUTOFF)
> {$
> MyMemoryPool<T> _pool;
> $}
> };
>
>
> This looks like yet another variant on static if<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf>.
Concepts Lite<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf>is
what the committee is looking at to address these sorts of issues.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e015372747b8eb004e2ada53c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29 July 2013 16:50, Brian Anderle <span dir=3D"ltr"><<a href=3D"mailt=
o:whattayabrian@gmail.com" target=3D"_blank">whattayabrian@gmail.com</a>>=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<br><div><br></div><div>So let's see an example of the proposal proper:=
</div><div><br></div><div style=3D"background-color:rgb(250,250,250);border=
:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D=
"color:#008">template</span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#008">class</span><span style> T</span><span style=3D"color:#66=
0">></span><span style><br>
</span><span style=3D"color:#008">class</span><span style> </span><span sty=
le=3D"color:#606">MyAllocator</span><span style><br></span><span style=3D"c=
olor:#660">{</span><span style><br>=A0</span><span style=3D"color:#606">MyA=
llocator</span><span style=3D"color:#660">()</span><span style><br>
=A0</span><span style=3D"color:#660">{</span><span style><br>=A0 =A0compile=
_if</span><span style=3D"color:#660">(</span><span style=3D"color:#008">siz=
eof</span><span style=3D"color:#660">(</span><span style>T</span><span styl=
e=3D"color:#660">)</span><span style> </span><span style=3D"color:#660"><=
;=3D</span><span style> MEMORY_CUTOFF</span><span style=3D"color:#660">)</s=
pan><span style><br>
=A0 =A0</span><span style=3D"color:#660">{</span><span style>$<br>=A0 =A0 =
=A0_pool</span><span style=3D"color:#660">.</span><span style=3D"color:#606=
">Initialize</span><span style=3D"color:#660">(...);</span><span style><br>=
=A0 =A0 =A0_usePool </span><span style=3D"color:#660">=3D</span><span style=
> </span><span style=3D"color:#008">true</span><span style=3D"color:#660">;=
</span><span style><br>
=A0 =A0$</span><span style=3D"color:#660">}</span><span style><br>=A0</span=
><span style=3D"color:#660">}</span><span style><br><br><br>=A0T </span><sp=
an style=3D"color:#660">*</span><span style> </span><span style=3D"color:#6=
06">Allocate</span><span style=3D"color:#660">()</span><span style><br>
=A0</span><span style=3D"color:#660">{</span><span style><br>=A0 =A0compile=
_if</span><span style=3D"color:#660">(</span><span style=3D"color:#008">siz=
eof</span><span style=3D"color:#660">(</span><span style>T</span><span styl=
e=3D"color:#660">)</span><span style> </span><span style=3D"color:#660"><=
;=3D</span><span style> MEMORY_CUTOFF</span><span style=3D"color:#660">)</s=
pan><span style><br>
=A0 =A0</span><span style=3D"color:#660">{</span><span style>$<br>=A0 =A0 =
=A0</span><span style=3D"color:#008">return</span><span style> _pool</span>=
<span style=3D"color:#660">.</span><span style=3D"color:#606">Allocate</spa=
n><span style=3D"color:#660">();</span><span style><br>
=A0 =A0$</span><span style=3D"color:#660">}</span><span style><br>=A0 =A0co=
mpile_else<br>=A0 =A0</span><span style=3D"color:#660">{</span><span style>=
$<br>=A0 =A0 =A0</span><span style=3D"color:#008">return</span><span style>=
</span><span style=3D"color:#008">new</span><span style> T</span><span sty=
le=3D"color:#660">;</span><span style><br>
=A0 =A0$</span><span style=3D"color:#660">}</span><span style><br>=A0</span=
><span style=3D"color:#660">}</span><span style><br><br><br>=A0compile_if</=
span><span style=3D"color:#660">(</span><span style=3D"color:#008">sizeof</=
span><span style=3D"color:#660">(</span><span style>T</span><span style=3D"=
color:#660">)</span><span style> </span><span style=3D"color:#660"><=3D<=
/span><span style> MEMORY_CUTOFF</span><span style=3D"color:#660">)</span><=
span style><br>
=A0</span><span style=3D"color:#660">{</span><span style>$<br>=A0 =A0</span=
><span style=3D"color:#606">MyMemoryPool</span><span style=3D"color:#660">&=
lt;</span><span style>T</span><span style=3D"color:#660">></span><span s=
tyle> _pool</span><span style=3D"color:#660">;</span><span style><br>
=A0$</span><span style=3D"color:#660">}</span><span style><br></span><span =
style=3D"color:#660">};</span></div></code></div><div><br></div><div><br></=
div></blockquote><div>This looks like yet another variant on <a href=3D"htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf">static if</=
a>.=A0 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n=
3701.pdf">Concepts Lite</a> is what the committee is looking at to address =
these sorts of issues.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e015372747b8eb004e2ada53c--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 29 Jul 2013 15:27:09 -0700 (PDT)
Raw View
------=_Part_1808_3243589.1375136829605
Content-Type: text/plain; charset=ISO-8859-1
On Monday, July 29, 2013 3:01:40 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 29 July 2013 16:50, Brian Anderle <whatta...@gmail.com <javascript:>>wrote:
>
>>
>>
>> So let's see an example of the proposal proper:
>>
>> template<class T>
>> class MyAllocator
>> {
>> MyAllocator()
>> {
>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>> {$
>> _pool.Initialize(...);
>> _usePool = true;
>> $}
>> }
>>
>>
>> T * Allocate()
>> {
>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>> {$
>> return _pool.Allocate();
>> $}
>> compile_else
>> {$
>> return new T;
>> $}
>> }
>>
>>
>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>> {$
>> MyMemoryPool<T> _pool;
>> $}
>> };
>>
>>
>> This looks like yet another variant on static if<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf>.
> Concepts Lite<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf>is what the committee is looking at to address these sorts of issues.
>
The primary thrust of what he's talking about is to make metaprogramming
work *conceptually* more like the rest of C++. Concepts Lite does not. It
only works at the function/type level, rather than the code level. This
forces you into more declarative coding<http://en.wikipedia.org/wiki/Declarative_programming>patterns rather than imperative
ones <http://en.wikipedia.org/wiki/Imperative_programming>.
Concepts Lite solves the problem of enable_if being Godawful to look at,
understand, and use. It solves the problem of making sure that types used
in a template do not violate the syntactic restrictions on those types. It
doesn't solve the basic problem of metaprogramming being a completely
different programming paradigm from regular C++.
Granted, I'm not sure how big of a problem that is. Personally, I tend away
from metaprogramming because it's so hard to do anything, not because of
the conceptual programming issue (then again, I'm not exactly a stranger to
declarative programming). Metaprogramming requires a lot of API cruft to do
anything of worth, from enable_if to typename usage and so forth. A lot of
code text is expended to do very simple (conceptually) things. Concepts
Lite will help make this much simpler and easier to use, and thus I'm much
more likely to use it.
Personally, I think that more C++ programmers will adopt metaprogramming
techniques as they become something that requires less horrible code to
write.
--
---
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_1808_3243589.1375136829605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, July 29, 2013 3:01:40 PM UTC-7, Nevin ":-)" Liber wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On 29 July 2013 16:50, Brian Anderle <=
span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"pJKQHtXPeBoJ">whatta...@gmail.com</a>></span> wrote:<br><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div><br></div><div>So let's see an example of the proposal proper:</di=
v><div><br></div><div style=3D"background-color:rgb(250,250,250);border:1px=
solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"col=
or:#008">template</span><span style=3D"color:#660"><</span><span style=
=3D"color:#008">class</span><span> T</span><span style=3D"color:#660">><=
/span><span><br>
</span><span style=3D"color:#008">class</span><span> </span><span style=3D"=
color:#606">MyAllocator</span><span><br></span><span style=3D"color:#660">{=
</span><span><br> </span><span style=3D"color:#606">MyAllocator</span>=
<span style=3D"color:#660">()</span><span><br>
</span><span style=3D"color:#660">{</span><span><br> comp=
ile_if</span><span style=3D"color:#660">(</span><span style=3D"color:#008">=
sizeof</span><span style=3D"color:#660">(</span><span>T</span><span style=
=3D"color:#660">)</span><span> </span><span style=3D"color:#660"><=3D</s=
pan><span> MEMORY_CUTOFF</span><span style=3D"color:#660">)</span><span><br=
>
</span><span style=3D"color:#660">{</span><span>$<br> &n=
bsp; _pool</span><span style=3D"color:#660">.</span><span style=3D"co=
lor:#606">Initialize</span><span style=3D"color:#660">(...);</span><span><b=
r> _usePool </span><span style=3D"color:#660">=3D</span>=
<span> </span><span style=3D"color:#008">true</span><span style=3D"color:#6=
60">;</span><span><br>
$</span><span style=3D"color:#660">}</span><span><br> </s=
pan><span style=3D"color:#660">}</span><span><br><br><br> T </span><sp=
an style=3D"color:#660">*</span><span> </span><span style=3D"color:#606">Al=
locate</span><span style=3D"color:#660">()</span><span><br>
</span><span style=3D"color:#660">{</span><span><br> comp=
ile_if</span><span style=3D"color:#660">(</span><span style=3D"color:#008">=
sizeof</span><span style=3D"color:#660">(</span><span>T</span><span style=
=3D"color:#660">)</span><span> </span><span style=3D"color:#660"><=3D</s=
pan><span> MEMORY_CUTOFF</span><span style=3D"color:#660">)</span><span><br=
>
</span><span style=3D"color:#660">{</span><span>$<br> &n=
bsp; </span><span style=3D"color:#008">return</span><span> _pool</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#606">Allocate</s=
pan><span style=3D"color:#660">();</span><span><br>
$</span><span style=3D"color:#660">}</span><span><br> &n=
bsp;compile_else<br> </span><span style=3D"color:#660">{</span>=
<span>$<br> </span><span style=3D"color:#008">return</sp=
an><span> </span><span style=3D"color:#008">new</span><span> T</span><span =
style=3D"color:#660">;</span><span><br>
$</span><span style=3D"color:#660">}</span><span><br> </s=
pan><span style=3D"color:#660">}</span><span><br><br><br> compile_if</=
span><span style=3D"color:#660">(</span><span style=3D"color:#008">sizeof</=
span><span style=3D"color:#660">(</span><span>T</span><span style=3D"color:=
#660">)</span><span> </span><span style=3D"color:#660"><=3D</span><span>=
MEMORY_CUTOFF</span><span style=3D"color:#660">)</span><span><br>
</span><span style=3D"color:#660">{</span><span>$<br> </s=
pan><span style=3D"color:#606">MyMemoryPool</span><span style=3D"color:#660=
"><</span><span>T</span><span style=3D"color:#660">></span><span> _po=
ol</span><span style=3D"color:#660">;</span><span><br>
$</span><span style=3D"color:#660">}</span><span><br></span><span sty=
le=3D"color:#660">};</span></div></code></div><div><br></div><div><br></div=
></blockquote><div>This looks like yet another variant on <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf" target=3D"_bla=
nk">static if</a>. <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2013/n3701.pdf" target=3D"_blank">Concepts Lite</a> is what the=
committee is looking at to address these sorts of issues.<br></div></div><=
/blockquote><div><br>The primary thrust of what he's talking about is to ma=
ke metaprogramming work <i>conceptually</i> more like the rest of C++. Conc=
epts Lite does not. It only works at the function/type level, rather than t=
he code level. This forces you into more <a href=3D"http://en.wikipedia.org=
/wiki/Declarative_programming">declarative coding</a> patterns rather than =
<a href=3D"http://en.wikipedia.org/wiki/Imperative_programming">imperative =
ones</a>.<br><br>Concepts Lite solves the problem of enable_if being Godawf=
ul to look at, understand, and use. It solves the problem of making sure th=
at types used in a template do not violate the syntactic restrictions on th=
ose types. It doesn't solve the basic problem of metaprogramming being a co=
mpletely different programming paradigm from regular C++.<br><br>Granted, I=
'm not sure how big of a problem that is. Personally, I tend away from meta=
programming because it's so hard to do anything, not because of the concept=
ual programming issue (then again, I'm not exactly a stranger to declarativ=
e programming). Metaprogramming requires a lot of API cruft to do anything =
of worth, from enable_if to typename usage and so forth. A lot of code text=
is expended to do very simple (conceptually) things. Concepts Lite will he=
lp make this much simpler and easier to use, and thus I'm much more likely =
to use it.<br><br>Personally, I think that more C++ programmers will adopt =
metaprogramming techniques as they become something that requires less horr=
ible code to write.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1808_3243589.1375136829605--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Mon, 29 Jul 2013 17:43:03 -0500
Raw View
--047d7bdc093426285c04e2ae3894
Content-Type: text/plain; charset=ISO-8859-1
On Jul 29, 2013, at 5:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
On Monday, July 29, 2013 3:01:40 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 29 July 2013 16:50, Brian Anderle <whatta...@gmail.com <javascript:>>wrote:
>
>>
>>
>> So let's see an example of the proposal proper:
>>
>> template<class T>
>> class MyAllocator
>> {
>> MyAllocator()
>> {
>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>> {$
>> _pool.Initialize(...);
>> _usePool = true;
>> $}
>> }
>>
>>
>> T * Allocate()
>> {
>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>> {$
>> return _pool.Allocate();
>> $}
>> compile_else
>> {$
>> return new T;
>> $}
>> }
>>
>>
>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>> {$
>> MyMemoryPool<T> _pool;
>> $}
>> };
>>
>>
>> This looks like yet another variant on static if<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf>.
> Concepts Lite<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf>is what the committee is looking at to address these sorts of issues.
>
The primary thrust of what he's talking about is to make metaprogramming
work *conceptually* more like the rest of C++. Concepts Lite does not. It
only works at the function/type level, rather than the code level. This
forces you into more declarative
coding<http://en.wikipedia.org/wiki/Declarative_programming>patterns
rather than imperative
ones <http://en.wikipedia.org/wiki/Imperative_programming>.
How does his proposal differ from the static if proposals? The reasoning
against it in n3613 seems applicable here.
--
---
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/.
--047d7bdc093426285c04e2ae3894
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>On Jul 29, 2013, at 5:27 PM, Nicol=
Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&g=
t; wrote:</div>
<div><br></div><blockquote type=3D"cite"><div>On Monday, July 29, 2013 3:01=
:40 PM UTC-7, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">
On 29 July 2013 16:50, Brian Anderle <span dir=3D"ltr"><<a href=3D"javas=
cript:" target=3D"_blank">whatta...@gmail.com</a>></span> wrote:<br><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">
<br><div><br></div><div>So let's see an example of the proposal proper:=
</div><div><br></div><div style=3D"background-color:rgb(250,250,250);border=
:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D=
"color:#008">template</span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#008">class</span><span> T</span><span style=3D"color:#660">>=
;</span><span><br>
</span><span style=3D"color:#008">class</span><span> </span><span style=3D"=
color:#606">MyAllocator</span><span><br></span><span style=3D"color:#660">{=
</span><span><br>=A0</span><span style=3D"color:#606">MyAllocator</span><sp=
an style=3D"color:#660">()</span><span><br>
=A0</span><span style=3D"color:#660">{</span><span><br>=A0 =A0compile_if</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#008">sizeof</s=
pan><span style=3D"color:#660">(</span><span>T</span><span style=3D"color:#=
660">)</span><span> </span><span style=3D"color:#660"><=3D</span><span> =
MEMORY_CUTOFF</span><span style=3D"color:#660">)</span><span><br>
=A0 =A0</span><span style=3D"color:#660">{</span><span>$<br>=A0 =A0 =A0_poo=
l</span><span style=3D"color:#660">.</span><span style=3D"color:#606">Initi=
alize</span><span style=3D"color:#660">(...);</span><span><br>=A0 =A0 =A0_u=
sePool </span><span style=3D"color:#660">=3D</span><span> </span><span styl=
e=3D"color:#008">true</span><span style=3D"color:#660">;</span><span><br>
=A0 =A0$</span><span style=3D"color:#660">}</span><span><br>=A0</span><span=
style=3D"color:#660">}</span><span><br><br><br>=A0T </span><span style=3D"=
color:#660">*</span><span> </span><span style=3D"color:#606">Allocate</span=
><span style=3D"color:#660">()</span><span><br>
=A0</span><span style=3D"color:#660">{</span><span><br>=A0 =A0compile_if</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#008">sizeof</s=
pan><span style=3D"color:#660">(</span><span>T</span><span style=3D"color:#=
660">)</span><span> </span><span style=3D"color:#660"><=3D</span><span> =
MEMORY_CUTOFF</span><span style=3D"color:#660">)</span><span><br>
=A0 =A0</span><span style=3D"color:#660">{</span><span>$<br>=A0 =A0 =A0</sp=
an><span style=3D"color:#008">return</span><span> _pool</span><span style=
=3D"color:#660">.</span><span style=3D"color:#606">Allocate</span><span sty=
le=3D"color:#660">();</span><span><br>
=A0 =A0$</span><span style=3D"color:#660">}</span><span><br>=A0 =A0compile_=
else<br>=A0 =A0</span><span style=3D"color:#660">{</span><span>$<br>=A0 =A0=
=A0</span><span style=3D"color:#008">return</span><span> </span><span styl=
e=3D"color:#008">new</span><span> T</span><span style=3D"color:#660">;</spa=
n><span><br>
=A0 =A0$</span><span style=3D"color:#660">}</span><span><br>=A0</span><span=
style=3D"color:#660">}</span><span><br><br><br>=A0compile_if</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#008">sizeof</span><span s=
tyle=3D"color:#660">(</span><span>T</span><span style=3D"color:#660">)</spa=
n><span> </span><span style=3D"color:#660"><=3D</span><span> MEMORY_CUTO=
FF</span><span style=3D"color:#660">)</span><span><br>
=A0</span><span style=3D"color:#660">{</span><span>$<br>=A0 =A0</span><span=
style=3D"color:#606">MyMemoryPool</span><span style=3D"color:#660"><</s=
pan><span>T</span><span style=3D"color:#660">></span><span> _pool</span>=
<span style=3D"color:#660">;</span><span><br>
=A0$</span><span style=3D"color:#660">}</span><span><br></span><span style=
=3D"color:#660">};</span></div></code></div><div><br></div><div><br></div><=
/blockquote><div>This looks like yet another variant on <a href=3D"http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf" target=3D"_blank=
">static if</a>.=A0 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2013/n3701.pdf" target=3D"_blank">Concepts Lite</a> is what the comm=
ittee is looking at to address these sorts of issues.<br>
</div></div></blockquote><div><br>The primary thrust of what he's talki=
ng about is to make metaprogramming work <i>conceptually</i> more like the =
rest of C++. Concepts Lite does not. It only works at the function/type lev=
el, rather than the code level. This forces you into more <a href=3D"http:/=
/en.wikipedia.org/wiki/Declarative_programming">declarative coding</a> patt=
erns rather than <a href=3D"http://en.wikipedia.org/wiki/Imperative_program=
ming">imperative ones</a>.<br>
</div></div></blockquote><div><br></div><div>How does his proposal differ f=
rom the static if proposals? =A0The reasoning against it in n3613 seems app=
licable here.</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bdc093426285c04e2ae3894--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 30 Jul 2013 01:46:28 +0300
Raw View
--047d7bd766de5931ae04e2ae43c4
Content-Type: text/plain; charset=ISO-8859-1
On 30 July 2013 01:43, Nevin Liber <nliber@gmail.com> wrote:
> On Jul 29, 2013, at 5:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> On Monday, July 29, 2013 3:01:40 PM UTC-7, Nevin ":-)" Liber wrote:
>>
>> On 29 July 2013 16:50, Brian Anderle <whatta...@gmail.com> wrote:
>>
>>>
>>>
>>> So let's see an example of the proposal proper:
>>>
>>> template<class T>
>>> class MyAllocator
>>> {
>>> MyAllocator()
>>> {
>>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>>> {$
>>> _pool.Initialize(...);
>>> _usePool = true;
>>> $}
>>> }
>>>
>>>
>>> T * Allocate()
>>> {
>>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>>> {$
>>> return _pool.Allocate();
>>> $}
>>> compile_else
>>> {$
>>> return new T;
>>> $}
>>> }
>>>
>>>
>>> compile_if(sizeof(T) <= MEMORY_CUTOFF)
>>> {$
>>> MyMemoryPool<T> _pool;
>>> $}
>>> };
>>>
>>>
>>> This looks like yet another variant on static if<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf>.
>> Concepts Lite<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3701.pdf>is what the committee is looking at to address these sorts of issues.
>>
>
> The primary thrust of what he's talking about is to make metaprogramming
> work *conceptually* more like the rest of C++. Concepts Lite does not. It
> only works at the function/type level, rather than the code level. This
> forces you into more declarative coding<http://en.wikipedia.org/wiki/Declarative_programming>patterns rather than imperative
> ones <http://en.wikipedia.org/wiki/Imperative_programming>.
>
>
> How does his proposal differ from the static if proposals? The reasoning
> against it in n3613 seems applicable here.
>
If you want metaprogramming that's more imperative than declarative, look
at Origin by Andrew Sutton,
and in particular
http://code.google.com/p/origin/source/browse/trunk/origin/type/traits.hpp
--
---
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/.
--047d7bd766de5931ae04e2ae43c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 30 July 2013 01:43, Nevin Liber <span dir=3D"ltr"><<a href=3D=
"mailto:nliber@gmail.com" target=3D"_blank">nliber@gmail.com</a>></span>=
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"><div><d=
iv class=3D"h5"><div>On Jul 29, 2013, at 5:27 PM, Nicol Bolas <<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t; wrote:</div>
<div><br></div><blockquote type=3D"cite"><div>On Monday, July 29, 2013 3:01=
:40 PM UTC-7, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
On 29 July 2013 16:50, Brian Anderle <span dir=3D"ltr"><<a>whatta...@gma=
il.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
<br><div><br></div><div>So let's see an example of the proposal proper:=
</div><div><br></div><div style=3D"background-color:rgb(250,250,250);border=
:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D=
"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(102,102,0)">&l=
t;</span><span style=3D"color:rgb(0,0,136)">class</span><span> T</span><spa=
n style=3D"color:rgb(102,102,0)">></span><span><br>
</span><span style=3D"color:rgb(0,0,136)">class</span><span> </span><span s=
tyle=3D"color:rgb(102,0,102)">MyAllocator</span><span><br></span><span styl=
e=3D"color:rgb(102,102,0)">{</span><span><br>=A0</span><span style=3D"color=
:rgb(102,0,102)">MyAllocator</span><span style=3D"color:rgb(102,102,0)">()<=
/span><span><br>
=A0</span><span style=3D"color:rgb(102,102,0)">{</span><span><br>=A0 =A0com=
pile_if</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"c=
olor:rgb(0,0,136)">sizeof</span><span style=3D"color:rgb(102,102,0)">(</spa=
n><span>T</span><span style=3D"color:rgb(102,102,0)">)</span><span> </span>=
<span style=3D"color:rgb(102,102,0)"><=3D</span><span> MEMORY_CUTOFF</sp=
an><span style=3D"color:rgb(102,102,0)">)</span><span><br>
=A0 =A0</span><span style=3D"color:rgb(102,102,0)">{</span><span>$<br>=A0 =
=A0 =A0_pool</span><span style=3D"color:rgb(102,102,0)">.</span><span style=
=3D"color:rgb(102,0,102)">Initialize</span><span style=3D"color:rgb(102,102=
,0)">(...);</span><span><br>
=A0 =A0 =A0_usePool </span><span style=3D"color:rgb(102,102,0)">=3D</span><=
span> </span><span style=3D"color:rgb(0,0,136)">true</span><span style=3D"c=
olor:rgb(102,102,0)">;</span><span><br>
=A0 =A0$</span><span style=3D"color:rgb(102,102,0)">}</span><span><br>=A0</=
span><span style=3D"color:rgb(102,102,0)">}</span><span><br><br><br>=A0T </=
span><span style=3D"color:rgb(102,102,0)">*</span><span> </span><span style=
=3D"color:rgb(102,0,102)">Allocate</span><span style=3D"color:rgb(102,102,0=
)">()</span><span><br>
=A0</span><span style=3D"color:rgb(102,102,0)">{</span><span><br>=A0 =A0com=
pile_if</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"c=
olor:rgb(0,0,136)">sizeof</span><span style=3D"color:rgb(102,102,0)">(</spa=
n><span>T</span><span style=3D"color:rgb(102,102,0)">)</span><span> </span>=
<span style=3D"color:rgb(102,102,0)"><=3D</span><span> MEMORY_CUTOFF</sp=
an><span style=3D"color:rgb(102,102,0)">)</span><span><br>
=A0 =A0</span><span style=3D"color:rgb(102,102,0)">{</span><span>$<br>=A0 =
=A0 =A0</span><span style=3D"color:rgb(0,0,136)">return</span><span> _pool<=
/span><span style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb=
(102,0,102)">Allocate</span><span style=3D"color:rgb(102,102,0)">();</span>=
<span><br>
=A0 =A0$</span><span style=3D"color:rgb(102,102,0)">}</span><span><br>=A0 =
=A0compile_else<br>=A0 =A0</span><span style=3D"color:rgb(102,102,0)">{</sp=
an><span>$<br>=A0 =A0 =A0</span><span style=3D"color:rgb(0,0,136)">return</=
span><span> </span><span style=3D"color:rgb(0,0,136)">new</span><span> T</s=
pan><span style=3D"color:rgb(102,102,0)">;</span><span><br>
=A0 =A0$</span><span style=3D"color:rgb(102,102,0)">}</span><span><br>=A0</=
span><span style=3D"color:rgb(102,102,0)">}</span><span><br><br><br>=A0comp=
ile_if</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"co=
lor:rgb(0,0,136)">sizeof</span><span style=3D"color:rgb(102,102,0)">(</span=
><span>T</span><span style=3D"color:rgb(102,102,0)">)</span><span> </span><=
span style=3D"color:rgb(102,102,0)"><=3D</span><span> MEMORY_CUTOFF</spa=
n><span style=3D"color:rgb(102,102,0)">)</span><span><br>
=A0</span><span style=3D"color:rgb(102,102,0)">{</span><span>$<br>=A0 =A0</=
span><span style=3D"color:rgb(102,0,102)">MyMemoryPool</span><span style=3D=
"color:rgb(102,102,0)"><</span><span>T</span><span style=3D"color:rgb(10=
2,102,0)">></span><span> _pool</span><span style=3D"color:rgb(102,102,0)=
">;</span><span><br>
=A0$</span><span style=3D"color:rgb(102,102,0)">}</span><span><br></span><s=
pan style=3D"color:rgb(102,102,0)">};</span></div></code></div><div><br></d=
iv><div><br></div></blockquote><div>This looks like yet another variant on =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pd=
f" target=3D"_blank">static if</a>.=A0 <a href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2013/n3701.pdf" target=3D"_blank">Concepts Lite</=
a> is what the committee is looking at to address these sorts of issues.<br=
>
</div></div></blockquote><div><br>The primary thrust of what he's talki=
ng about is to make metaprogramming work <i>conceptually</i> more like the =
rest of C++. Concepts Lite does not. It only works at the function/type lev=
el, rather than the code level. This forces you into more <a href=3D"http:/=
/en.wikipedia.org/wiki/Declarative_programming" target=3D"_blank">declarati=
ve coding</a> patterns rather than <a href=3D"http://en.wikipedia.org/wiki/=
Imperative_programming" target=3D"_blank">imperative ones</a>.<br>
</div></div></blockquote><div><br></div></div></div><div>How does his propo=
sal differ from the static if proposals? =A0The reasoning against it in n36=
13 seems applicable here.</div></div></blockquote><div><br></div><div>If yo=
u want metaprogramming that's more imperative than declarative, look at=
Origin by Andrew Sutton,<br>
and in particular<br><a href=3D"http://code.google.com/p/origin/source/brow=
se/trunk/origin/type/traits.hpp">http://code.google.com/p/origin/source/bro=
wse/trunk/origin/type/traits.hpp</a><br><br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bd766de5931ae04e2ae43c4--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Tue, 30 Jul 2013 12:01:03 +0200
Raw View
On Mon, Jul 29, 2013 at 11:50 PM, Brian Anderle <whattayabrian@gmail.com> wrote:
>
> It is not that this lets us to do something we could not before, but rather
> lets us do it in a way that mirrors the way we are used to coding and should
> help bridge the gap to getting more programmers, myself included, into group
> 3.
>
I am used to coding in a functional way and also want the non-template
parts of the language to let me do things in a way that mirrors the
way I am used to coding.
--
---
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: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Aug 2013 06:02:33 -0700 (PDT)
Raw View
------=_Part_2921_6657164.1375966953780
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, July 30, 2013 3:01:03 AM UTC-7, R. Martinho Fernandes wrote:
>
> On Mon, Jul 29, 2013 at 11:50 PM, Brian Anderle <whatta...@gmail.com<javascript:>>
> wrote:
> >
> > It is not that this lets us to do something we could not before, but
> rather
> > lets us do it in a way that mirrors the way we are used to coding and
> should
> > help bridge the gap to getting more programmers, myself included, into
> group
> > 3.
> >
>
> I am used to coding in a functional way and also want the non-template
> parts of the language to let me do things in a way that mirrors the
> way I am used to coding.
>
That doesn't invalidate his argument. C++ is an imperative language...
except for metaprogramming where it suddenly becomes declarative. That's
pretty schizophrenic from a language design and user perspective. There's
no reason to *want* to make a language like that. There's just no advantage
to it from the point of view of someone learning the language. Whether
you're used to declarative or imperative or even *both*, it doesn't help
the language to switch back and forth the way it does.
Indeed, thanks to features like constexpr functions and types, even
metaprogramming is becoming less declarative.
Now granted, what he wants is generally just not *practical*. It's just a
variation of `static if`, whose problems have been discussed. But these are
primarily problems with language design and implement-ability, and all are
problems that could have been worked out when templates were originally
introduced decades ago. Concepts lite is superior primarily in that it's *
simpler* to specify and implement, not fundamentally better from a user
perspective.
It's superior from the practical need for *some* solution, not in the
idealistic need for the *best* solution.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2921_6657164.1375966953780
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, July 30, 2013 3:01:03 AM UTC-7, R. Martinho Fernandes w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jul 29, 2013 at 1=
1:50 PM, Brian Anderle <<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"hagwuKWtI_UJ">whatta...@gmail.com</a>> wrote:
<br>>
<br>> It is not that this lets us to do something we could not before, b=
ut rather
<br>> lets us do it in a way that mirrors the way we are used to coding =
and should
<br>> help bridge the gap to getting more programmers, myself included, =
into group
<br>> 3.
<br>>
<br>
<br>I am used to coding in a functional way and also want the non-template
<br>parts of the language to let me do things in a way that mirrors the
<br>way I am used to coding.
<br></blockquote><div><br>That doesn't invalidate his argument. C++ is an i=
mperative language... except for metaprogramming where it suddenly becomes =
declarative. That's pretty schizophrenic from a language design and user pe=
rspective. There's no reason to <i>want</i> to make a language like that. T=
here's just no advantage to it from the point of view of someone learning t=
he language. Whether you're used to declarative or imperative or even <i>bo=
th</i>, it doesn't help the language to switch back and forth the way it do=
es.<br><br>Indeed, thanks to features like constexpr functions and types, e=
ven metaprogramming is becoming less declarative.<br><br>Now granted, what =
he wants is generally just not <i>practical</i>. It's just a variation of `=
static if`, whose problems have been discussed. But these are primarily pro=
blems with language design and implement-ability, and all are problems that=
could have been worked out when templates were originally introduced decad=
es ago. Concepts lite is superior primarily in that it's <i>simpler</i> to =
specify and implement, not fundamentally better from a user perspective.<br=
><br>It's superior from the practical need for <i>some</i> solution, not in=
the idealistic need for the <i>best</i> solution.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_2921_6657164.1375966953780--
.
Author: Alex B <devalexb@gmail.com>
Date: Thu, 8 Aug 2013 17:44:31 -0700 (PDT)
Raw View
------=_Part_220_24277222.1376009071763
Content-Type: text/plain; charset=ISO-8859-1
I kinda agree with most of what you say. Metaprogramming in C++ is really
another language. Until it becomes more imperative, it will remain
something used only by very advanced users (the few caring about
metaprogramming).
I find it hard to believe that after all these years of users requesting an
"evil static if" that it is still out of the radar. We all know there are
all sorts of problems with an "all in" (evil) version of static if, but
there surely could be a restricted static if that could satisfy most needs.
Simply consider a static if with the following restrictions:
- It can only be used where a regular "if" is usually used (that is within
function or block scope)
- A new nested block scope would be introduced by a static if (just like
for regular if)
So with such restrictions you wouldn't be able to conditionally declare
something.
That would mean:
static if (condition)
{
int a = 0;
}
else
{
string a = "";
}
a++; // error: a is not declared in this scope (wether or not condition is
met, just like for a normal if)
Really, should we always throw static if ideas to garbage? I think it is
just a matter of finding the right restrictions for it.
On Thursday, August 8, 2013 9:02:33 AM UTC-4, Nicol Bolas wrote:
>
>
>
> On Tuesday, July 30, 2013 3:01:03 AM UTC-7, R. Martinho Fernandes wrote:
>>
>> On Mon, Jul 29, 2013 at 11:50 PM, Brian Anderle <whatta...@gmail.com>
>> wrote:
>> >
>> > It is not that this lets us to do something we could not before, but
>> rather
>> > lets us do it in a way that mirrors the way we are used to coding and
>> should
>> > help bridge the gap to getting more programmers, myself included, into
>> group
>> > 3.
>> >
>>
>> I am used to coding in a functional way and also want the non-template
>> parts of the language to let me do things in a way that mirrors the
>> way I am used to coding.
>>
>
> That doesn't invalidate his argument. C++ is an imperative language...
> except for metaprogramming where it suddenly becomes declarative. That's
> pretty schizophrenic from a language design and user perspective. There's
> no reason to *want* to make a language like that. There's just no
> advantage to it from the point of view of someone learning the language.
> Whether you're used to declarative or imperative or even *both*, it
> doesn't help the language to switch back and forth the way it does.
>
> Indeed, thanks to features like constexpr functions and types, even
> metaprogramming is becoming less declarative.
>
> Now granted, what he wants is generally just not *practical*. It's just a
> variation of `static if`, whose problems have been discussed. But these are
> primarily problems with language design and implement-ability, and all are
> problems that could have been worked out when templates were originally
> introduced decades ago. Concepts lite is superior primarily in that it's *
> simpler* to specify and implement, not fundamentally better from a user
> perspective.
>
> It's superior from the practical need for *some* solution, not in the
> idealistic need for the *best* solution.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_220_24277222.1376009071763
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I kinda agree with most of what you say. Metaprogramming i=
n C++ is really another language. Until it becomes more imperative, it will=
remain something used only by very advanced users (the few caring about me=
taprogramming).<div><br></div><div>I find it hard to believe that after all=
these years of users requesting an "evil static if" that it is still out o=
f the radar. We all know there are all sorts of problems with an "all in" (=
evil) version of static if, but there surely could be a restricted static i=
f that could satisfy most needs. Simply consider a static if with the follo=
wing restrictions:</div><div>- It can only be used where a regular "if" is =
usually used (that is within function or block scope)</div><div>- A new nes=
ted block scope would be introduced by a static if (just like for regular i=
f)</div><div><br></div><div>So with such restrictions you wouldn't be able =
to conditionally declare something.</div><div><br></div><div>That would mea=
n:</div><div><br></div><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">static</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #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"styled-b=
y-prettify">condition</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">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">0</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"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">else</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><span style=3D"color: #008;" class=3D"styled-by-prettify">string</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" 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><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>a</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>++;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// error: a is =
not declared in this scope (wether or not condition is met, just like for a=
normal if)</span></div></code></div><div><br></div><div>Really, should we =
always throw static if ideas to garbage? I think it is just a matter of fin=
ding the right restrictions for it.</div><div><br><div><br>On Thursday, Aug=
ust 8, 2013 9:02:33 AM UTC-4, Nicol Bolas wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><br><br>On Tuesday, July 30, 2013 3:01:03 AM UTC-7, R. Ma=
rtinho Fernandes wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jul =
29, 2013 at 11:50 PM, Brian Anderle <<a>whatta...@gmail.com</a>> wrot=
e:
<br>>
<br>> It is not that this lets us to do something we could not before, b=
ut rather
<br>> lets us do it in a way that mirrors the way we are used to coding =
and should
<br>> help bridge the gap to getting more programmers, myself included, =
into group
<br>> 3.
<br>>
<br>
<br>I am used to coding in a functional way and also want the non-template
<br>parts of the language to let me do things in a way that mirrors the
<br>way I am used to coding.
<br></blockquote><div><br>That doesn't invalidate his argument. C++ is an i=
mperative language... except for metaprogramming where it suddenly becomes =
declarative. That's pretty schizophrenic from a language design and user pe=
rspective. There's no reason to <i>want</i> to make a language like that. T=
here's just no advantage to it from the point of view of someone learning t=
he language. Whether you're used to declarative or imperative or even <i>bo=
th</i>, it doesn't help the language to switch back and forth the way it do=
es.<br><br>Indeed, thanks to features like constexpr functions and types, e=
ven metaprogramming is becoming less declarative.<br><br>Now granted, what =
he wants is generally just not <i>practical</i>. It's just a variation of `=
static if`, whose problems have been discussed. But these are primarily pro=
blems with language design and implement-ability, and all are problems that=
could have been worked out when templates were originally introduced decad=
es ago. Concepts lite is superior primarily in that it's <i>simpler</i> to =
specify and implement, not fundamentally better from a user perspective.<br=
><br>It's superior from the practical need for <i>some</i> solution, not in=
the idealistic need for the <i>best</i> solution.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_220_24277222.1376009071763--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Aug 2013 18:28:56 -0700 (PDT)
Raw View
------=_Part_188_32743399.1376011736960
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 8, 2013 5:44:31 PM UTC-7, Alex B wrote:
>
> I kinda agree with most of what you say. Metaprogramming in C++ is really
> another language. Until it becomes more imperative, it will remain
> something used only by very advanced users (the few caring about
> metaprogramming).
>
I disagree with this. Deep metaprogramming is hard, and will likely be
avoided by non-experts. However, there is a lot of "lite" metaprogramming
tasks that people could do, but don't. And this is what keeps people from
climbing the tree of metaprogramming: getting into even *basic* uses of it
requires so much pain.
For example, there are times when I want the user to "derive a class from
some type", but I would prefer to use a template for compile-time
polymorphism rather than a virtual derived class. So the user implements
against a prototype, and the class he writes could include a number of
optional functions (with fallbacks handled internally).
However, there are two fundamental things that generally prevent me from
doing that.
1: It is *very* difficult to clearly explain what the requirements are to
the user *within the language*. If I give someone a class to derive from,
it's very easy for them to see what they have to implement. They can see if
implementing a virtual function is optional or not, and so forth. With
templates, this simply doesn't exist.
2: Actually implementing the code for such a type is an absolute nightmare
of Godawful code, particularly with regard to optional functions.
std::enable_if is an absolute atrocity, used only because it *works*, not
because it is in any way reasonable. Something as simple as checking if a
type has a particular member function requires a monstrosity of code.
For an example, here's the setup work I had to do to check to see if a
given template type has a member function with a certain name:
#define IF_HAS_MEM_FUNC(func, name) \
template<typename T, typename Sign> \
struct name { \
typedef char yes[1]; \
typedef char no [2]; \
template <typename U, U> struct type_check; \
template <typename _1> static yes &chk(type_check<Sign, &_1::func> *); \
template <typename > static no &chk(...); \
static bool const value = sizeof(chk<T>(0)) == sizeof(yes); \
}
....
IF_HAS_MEM_FUNC(Character, has_character)
....
//Actual use:
template<typename T>
typename std::enable_if<_detail::has_character<T,
bool(T::*)(unsigned char, int, int)>::value, bool>::type
ForwardCharacter(unsigned char key, int x, int y)
{
return m_pApp->Character(key, x, y);
}
template<typename T>
typename _detail::activate_if<!_detail::has_character<T,
bool(T::*)(unsigned char, int, int)>::value, bool>::type
ForwardCharacter(unsigned char key, int x, int y)
{
return false;
}
Well, that's pretty horrible. Now, compare the version for static_if:
template<typename T> bool ForwardCharacter(unsigned char key, int x, int y)
{
static if(_detail::has_character<T, bool(T::*)(unsigned char, int, int)>::
value)
{
return m_pApp->Character(key, x, y);
}
else
{
return false;
}
}
It has much of the same boilerplate, so it still has some visual syntax
issues. But at least the function declaration is legible. And on the plus
side, it's just one function.
And here's the version for the current concepts_lite proposal:
template<typename T>
concept bool has_character()
{
return requires(T t, unsigned int key, int x, int y) {{t.Character(key, x,y
)} -> bool};
}
template<has_character T>
bool ForwardCharacter(unsigned char key, int x, int y)
{
return m_pApp->Character(key, x, y);
}
template<typename T>
bool ForwardCharacter(unsigned char key, int x, int y)
{
return false;
}
This requires a small bit of boilerplate, but that boilerplate *far more
legible* than the mass of stuff that both static_if and enable_if required.
An actual human being can read that code and know what it's doing, whereas
the macro is something I have to look up or copy-and-paste every time I
want to use it. Equally importantly, it doesn't take that much expertise to
learn to *write* that code.
The only downside of this compared to static_if is that you have two
functions again, rather than the imperative approach of one function with
conditional logic. Even so, this is still superior to what we do today, and
I think most C++ programmers can understand it. Sure, more complex examples
may still be baffling, but the main point is that it lowers the bar for C++
programmers to *try* metaprogramming.
I find it hard to believe that after all these years of users requesting an
> "evil static if" that it is still out of the radar.
>
These... two years? I don't recall anyone requesting static_if until
relatively recently. The focus was primarily on the full concepts proposal.
--
---
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_188_32743399.1376011736960
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 8, 2013 5:44:31 PM UTC-7, Alex B wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I kinda agre=
e with most of what you say. Metaprogramming in C++ is really another langu=
age. Until it becomes more imperative, it will remain something used only b=
y very advanced users (the few caring about metaprogramming).</div></blockq=
uote><div><br>I disagree with this. Deep metaprogramming is hard, and will =
likely be avoided by non-experts. However, there is a lot of "lite" metapro=
gramming tasks that people could do, but don't. And this is what keeps peop=
le from climbing the tree of metaprogramming: getting into even <i>basic</i=
> uses of it requires so much pain.<br><br>For example, there are times whe=
n I want the user to "derive a class from some type", but I would prefer to=
use a template for compile-time polymorphism rather than a virtual derived=
class. So the user implements against a prototype, and the class he writes=
could include a number of optional functions (with fallbacks handled inter=
nally).<br><br>However, there are two fundamental things that generally pre=
vent me from doing that.<br><br>1: It is <i>very</i> difficult to clearly e=
xplain what the requirements are to the user <i>within the language</i>. If=
I give someone a class to derive from, it's very easy for them to see what=
they have to implement. They can see if implementing a virtual function is=
optional or not, and so forth. With templates, this simply doesn't exist.<=
br><br>2: Actually implementing the code for such a type is an absolute nig=
htmare of Godawful code, particularly with regard to optional functions. st=
d::enable_if is an absolute atrocity, used only because it <i>works</i>, no=
t because it is in any way reasonable. Something as simple as checking if a=
type has a particular member function requires a monstrosity of code.<br><=
br>For an example, here's the setup work I had to do to check to see if a g=
iven template type has a member function with a certain name:<br><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: #800;" class=3D"styled-by-prettify">#define</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> IF_HAS_MEM_FUNC</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> name</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> &=
nbsp; =
</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">\</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">template</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</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">typename</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Sign</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"s=
tyled-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><span style=3D"color: #008=
;" class=3D"styled-by-prettify">struct</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"> &nb=
sp; &=
nbsp; </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">typedef</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> yes</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &=
nbsp; =
&nbs=
p;</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">typedef</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">no</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: #066;" class=3D"style=
d-by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &=
nbsp; =
&nbs=
p;</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">template<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" class=
=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">struct</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> type_check</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &n=
bsp; </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">\</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> _1</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">static</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> yes </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">chk</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">type_check</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Sign</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">_1</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">func</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </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> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</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">typename</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">static</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">no</span><span style=3D"color: #000;" class=3D"styled-by-prettify">  =
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">chk</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> &nb=
sp; </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><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">static</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> value </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">chk</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">>(</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">yes</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">\</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br>IF_HAS_MEM_FUNC</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Character</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> has_c=
haracter</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span=
style=3D"color: #800;" class=3D"styled-by-prettify">//Actual use:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> <br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cla=
ss=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-b=
y-prettify">enable_if</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">_detail</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">has_ch=
aracter</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> <br> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">::*)(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">unsigned</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">char</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">int</sp=
an><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">int</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)>::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">value</span><span style=3D"color: #660;" c=
lass=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">bool</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
type<br> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">ForwardCharacter</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">unsigned</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ch=
ar</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> key</sp=
an><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">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" c=
lass=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">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> y</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><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> m_pApp</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">-></span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Character</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">key</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
y</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><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=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"styled-=
by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> _detail</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>activate_if</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_de=
tail</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">has_character<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">T</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> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::*)(</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">unsigned</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">char</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><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"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)>::</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">value</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=
">bool</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">type<br>=
</span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">ForwardCharacter</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>unsigned</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> key</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">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x</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=
">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</s=
pan><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><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">false</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-prett=
ify"><br></span></div></code></div><br>Well, that's pretty horrible. Now, c=
ompare the version for static_if:<br><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: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">ForwardCharact=
er</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> key</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> x</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">int</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> y</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> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">static</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_detail</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">has_character</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">bool</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::*)(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">unsi=
gned</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">char</span><spa=
n 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">int</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"style=
d-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)>::</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">value</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> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> m_pApp</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Character</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">key</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">else</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">false</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"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><br>It has much of the same boilerpl=
ate, so it still has some visual syntax issues. But at least the function d=
eclaration is legible. And on the plus side, it's just one function.<br><br=
>And here's the version for the current concepts_lite proposal:<br><br><div=
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">concept</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> has_character</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> requires</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">T t</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">unsigned</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> key</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x</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">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> y</span><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">t</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Character</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">key</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> y</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: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">bool</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"style=
d-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">has_character T</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">bo=
ol</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">ForwardCharacter<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">unsigned</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> key</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"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> x</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">int</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> y</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;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> m_pApp</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">-></span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Character</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">key</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"col=
or: #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><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">typename</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">ForwardCharacter</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">unsigned</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">char</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> key</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> y</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"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">false</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code><=
/div><br>This requires a small bit of boilerplate, but that boilerplate <i>=
far more legible</i> than the mass of stuff that both static_if and enable_=
if required. An actual human being can read that code and know what it's do=
ing, whereas the macro is something I have to look up or copy-and-paste eve=
ry time I want to use it. Equally importantly, it doesn't take that much ex=
pertise to learn to <i>write</i> that code.<br><br>The only downside of thi=
s compared to static_if is that you have two functions again, rather than t=
he imperative approach of one function with conditional logic. Even so, thi=
s is still superior to what we do today, and I think most C++ programmers c=
an understand it. Sure, more complex examples may still be baffling, but th=
e main point is that it lowers the bar for C++ programmers to <i>try</i> me=
taprogramming.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div></div><div>I find it hard to believe that after all the=
se years of users requesting an "evil static if" that it is still out of th=
e radar.</div></div></blockquote><div><br>These... two years? I don't recal=
l anyone requesting static_if until relatively recently. The focus was prim=
arily on the full concepts proposal.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_188_32743399.1376011736960--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Thu, 8 Aug 2013 20:42:02 -0500
Raw View
--089e0149528e9dd99404e379e15f
Content-Type: text/plain; charset=ISO-8859-1
On Aug 8, 2013, at 7:44 PM, Alex B <devalexb@gmail.com> wrote:
static if (condition)
{
int a = 0;
}
else
{
string a = "";
}
a++; // error: a is not declared in this scope (wether or not condition is
met, just like for a normal if)
How does this differ from regular if statements?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0149528e9dd99404e379e15f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>On Aug 8, 2013, at 7:44 PM, Alex B=
<<a href=3D"mailto:devalexb@gmail.com">devalexb@gmail.com</a>> wrote=
:</div>
<div><br></div><blockquote type=3D"cite"><div class=3D"prettyprint" style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wor=
d-wrap:break-word"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color:#008" class=3D"styled-by-prettify">static</span><spa=
n style=3D"color:#000" class=3D"styled-by-prettify"> </span><span style=3D"=
color:#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"styled-by-p=
rettify">condition</span><span style=3D"color:#660" class=3D"styled-by-pret=
tify">)</span><span style=3D"color:#000" class=3D"styled-by-prettify"><br>
</span><span style=3D"color:#660" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color:#000" class=3D"styled-by-prettify"><br>=A0 =A0 </span><spa=
n style=3D"color:#008" class=3D"styled-by-prettify">int</span><span style=
=3D"color:#000" class=3D"styled-by-prettify"> a </span><span style=3D"color=
:#660" class=3D"styled-by-prettify">=3D</span><span style=3D"color:#000" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color:#066" class=3D"styl=
ed-by-prettify">0</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:#660" class=3D"styled-by-prettify">}</span><spa=
n style=3D"color:#000" class=3D"styled-by-prettify"><br></span><span style=
=3D"color:#008" class=3D"styled-by-prettify">else</span><span style=3D"colo=
r:#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>=A0 =A0 </span><spa=
n style=3D"color:#008" class=3D"styled-by-prettify">string</span><span styl=
e=3D"color:#000" class=3D"styled-by-prettify"> a </span><span style=3D"colo=
r:#660" class=3D"styled-by-prettify">=3D</span><span style=3D"color:#000" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color:#080" class=3D"sty=
led-by-prettify">""</span><span style=3D"color:#660" class=3D"sty=
led-by-prettify">;</span><span style=3D"color:#000" class=3D"styled-by-pret=
tify"><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>a</span><span style=
=3D"color:#660" class=3D"styled-by-prettify">++;</span><span style=3D"color=
:#000" class=3D"styled-by-prettify"> </span><span style=3D"color:#800" clas=
s=3D"styled-by-prettify">// error: a is not declared in this scope (wether =
or not condition is met, just like for a normal if)</span></div>
</code></div><div></div></blockquote><br><div>How does this differ from reg=
ular if statements?</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0149528e9dd99404e379e15f--
.
Author: Alex B <devalexb@gmail.com>
Date: Thu, 8 Aug 2013 23:03:04 -0400
Raw View
--089e0141a0dc705d2104e37b03f0
Content-Type: text/plain; charset=ISO-8859-1
> I disagree with this.
>
Ok... and I still agree with you.
> The only downside of this compared to static_if is that you have two
> functions again, rather than the imperative approach of one function with
> conditional logic. Even so, this is still superior to what we do today, and
> I think most C++ programmers can understand it. Sure, more complex examples
> may still be baffling, but the main point is that it lowers the bar for C++
> programmers to *try* metaprogramming.
>
Agreed that concepts will help a lot and it solves different (but crucial)
problems. It will make those kinds of overloads/specialization much easier
to write and read; I am far from being against it. But for a lot of users,
the simple fact of having to define several overloads is tedious.
Note that you could combine best of both and rewrite your static if example
to use a concept:
static if(has_character<T>())
...
>
> These... two years? I don't recall anyone requesting static_if until
> relatively recently. The focus was primarily on the full concepts proposal.
>
I admit it was a bit overstated. Still, ever since the D language
introduced such a feature, many people wondered if it would be interesting
for C++ (not talking about official proposals but general interest).
--
---
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/.
--089e0141a0dc705d2104e37b03f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div>I disagree with this. </div></div>
</blockquote><div><br></div><div>Ok... and I still agree with you.</div><di=
v>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex">
<div dir=3D"ltr"><div>The only downside of this compared to static_if is th=
at you have two functions again, rather than the imperative approach of one=
function with conditional logic. Even so, this is still superior to what w=
e do today, and I think most C++ programmers can understand it. Sure, more =
complex examples may still be baffling, but the main point is that it lower=
s the bar for C++ programmers to <i>try</i> metaprogramming.<br>
</div></div></blockquote><div><br></div><div>Agreed that concepts will help=
a lot and it solves different (but crucial) problems. It will make those k=
inds of overloads/specialization much easier to write and read; I am far fr=
om being against it. But for a lot of users, the simple fact of having to d=
efine several overloads is tedious.</div>
<div><br></div><div>Note that you could combine best of both and rewrite yo=
ur static if example to use a concept:</div><div><span style=3D"font-family=
:monospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">static</sp=
an><span style=3D"font-family:monospace;background-color:rgb(250,250,250)">=
=A0</span><span style=3D"font-family:monospace;background-color:rgb(250,250=
,250);color:rgb(0,0,136)">if</span><span style=3D"font-family:monospace;bac=
kground-color:rgb(250,250,250);color:rgb(102,102,0)">(</span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250)">has_character</sp=
an><span style=3D"font-family:monospace;background-color:rgb(250,250,250);c=
olor:rgb(102,102,0)"><</span><span style=3D"font-family:monospace;backgr=
ound-color:rgb(250,250,250)">T>()</span><span style=3D"font-family:monos=
pace;background-color:rgb(250,250,250);color:rgb(102,102,0)">)</span><span =
style=3D"font-family:monospace;background-color:rgb(250,250,250)"><br>
=A0=A0<font color=3D"#666600">...</font></span><br></div><div>=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div dir=3D"ltr"><div><br>These... two years? I don't recall anyone req=
uesting static_if until relatively recently. The focus was primarily on the=
full concepts proposal.</div></div></blockquote><div><br></div>
<div>I admit it was a bit overstated. Still, ever since the D language intr=
oduced such a feature, many people wondered=A0if it would be interesting fo=
r C++ (not talking about official proposals but general interest).</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0141a0dc705d2104e37b03f0--
.
Author: Alex B <devalexb@gmail.com>
Date: Thu, 8 Aug 2013 23:28:08 -0400
Raw View
--089e0141a0dc0829db04e37b5db2
Content-Type: text/plain; charset=ISO-8859-1
> How does this differ from regular if statements?
>
> That is part of my point: that it should pretty much be used in contexts
similar to regular if statements. The only difference would be that the
unchosen branches would not be compiled. So it could be nothing more than
that: a "static version" of the regular if.
Still, even with those restrictions, Nicol static if example would work
(but a regular if wouldn't).
Consider also the (interesting) use case implying auto return type
deduction described in the following post that would work even with those
restrictions:
https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/rIMWxd5W8ys
What I suggest is that static if work for these cases where it doesn't
introduce conditional declarations. But proposal N3329 goes much further
than that and propose a static if that could be used almost everywhere
(like at class scope) and allow it to do conditional declaration. A lot of
people agree it shouldn't go that far and that is why I am proposing a
restricted version.
--
---
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/.
--089e0141a0dc0829db04e37b5db2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"auto"><div>How does this differ from regular if statements?</di=
v></div><div class=3D""><div class=3D"h5">
<p></p></div></div></blockquote></div>That is part of my point: that it sho=
uld pretty much be used in contexts similar to regular if statements. The o=
nly difference would be that the unchosen branches would not be compiled. S=
o it could be nothing more than that: a "static version" of the r=
egular if.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Still, even=
with those restrictions, Nicol static if example would work (but a regular=
if wouldn't).</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">
Consider also the (interesting) use case implying auto return type deductio=
n described in the following post that would work even with those restricti=
ons:</div><div class=3D"gmail_extra"><a href=3D"https://groups.google.com/a=
/isocpp.org/forum/#!topic/concepts/rIMWxd5W8ys">https://groups.google.com/a=
/isocpp.org/forum/#!topic/concepts/rIMWxd5W8ys</a><br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">What =
I suggest is that static if work for these cases where it doesn't intro=
duce conditional declarations. But proposal N3329 goes much further than th=
at and propose a static if that could be used almost everywhere (like at cl=
ass scope) and allow it to do conditional declaration. A lot of people agre=
e it shouldn't go that far and that is why I am proposing a restricted =
version.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0141a0dc0829db04e37b5db2--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 8 Aug 2013 23:45:41 -0500
Raw View
--047d7b677116c3874c04e37c74ef
Content-Type: text/plain; charset=ISO-8859-1
On 8 August 2013 22:28, Alex B <devalexb@gmail.com> wrote:
>
> How does this differ from regular if statements?
>>
>> That is part of my point: that it should pretty much be used in contexts
> similar to regular if statements. The only difference would be that the
> unchosen branches would not be compiled.
>
Why doesn't normal if and optimization take care of this? This sounds like
a non-problem.
> Still, even with those restrictions, Nicol static if example would work
> (but a regular if wouldn't).
>
But there is a fairly simple way with concepts lite to express it, even if
it bothers your aesthetics.
Consider also the (interesting) use case implying auto return type
> deduction described in the following post that would work even with those
> restrictions:
> https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/rIMWxd5W8ys
>
I'm pretty sure I already commented on it there. :-)
> But proposal N3329 goes much further than that and propose a static if
> that could be used almost everywhere (like at class scope) and allow it to
> do conditional declaration. A lot of people agree it shouldn't go that far
> and that is why I am proposing a restricted version.
>
It's your time to spend writing the proposal and coming to meetings to
champion it. Keep in mind that there was strong concensus on the committee
not to revisit static if until after concepts lite.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b677116c3874c04e37c74ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 8 August 2013 22:28, Alex B <span dir=3D"ltr"><<a href=3D"mailto:deva=
lexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>></span> wrote:<=
br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"im"><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex">
<div dir=3D"auto"><div>How does this differ from regular if statements?</di=
v></div><div><div>
<p></p></div></div></blockquote></div></div>That is part of my point: that =
it should pretty much be used in contexts similar to regular if statements.=
The only difference would be that the unchosen branches would not be compi=
led.</div>
</div></blockquote><div><br></div><div>Why doesn't normal if and optimi=
zation take care of this? =A0This sounds like a non-problem.</div><div>=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">Still, even with those restrict=
ions, Nicol static if example would work (but a regular if wouldn't).</=
div></div></blockquote><div><br></div><div>But there is a fairly simple way=
with concepts lite to express it, even if it bothers your aesthetics.=A0</=
div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra">Consider also the (interesting) use case implying auto ret=
urn type deduction described in the following post that would work even wit=
h those restrictions:</div>
<div class=3D"gmail_extra"><a href=3D"https://groups.google.com/a/isocpp.or=
g/forum/#!topic/concepts/rIMWxd5W8ys" target=3D"_blank">https://groups.goog=
le.com/a/isocpp.org/forum/#!topic/concepts/rIMWxd5W8ys</a></div></div></blo=
ckquote>
<div><br></div><div>I'm pretty sure I already commented on it there. :-=
)</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra">
But proposal N3329 goes much further than that and propose a static if that=
could be used almost everywhere (like at class scope) and allow it to do c=
onditional declaration. A lot of people agree it shouldn't go that far =
and that is why I am proposing a restricted version.</div>
</div></blockquote><div><br></div><div>It's your time to spend writing =
the proposal and coming to meetings to champion it. =A0Keep in mind that th=
ere was strong concensus on the committee not to revisit static if until af=
ter concepts lite.</div>
</div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=
=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b677116c3874c04e37c74ef--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 8 Aug 2013 22:26:37 -0700 (PDT)
Raw View
------=_Part_22_11383612.1376025997767
Content-Type: text/plain; charset=ISO-8859-1
On Friday, August 9, 2013 9:28:56 AM UTC+8, Nicol Bolas wrote:
>
> 2: Actually implementing the code for such a type is an absolute nightmare
> of Godawful code, particularly with regard to optional functions.
> std::enable_if is an absolute atrocity, used only because it *works*, not
> because it is in any way reasonable. Something as simple as checking if a
> type has a particular member function requires a monstrosity of code.
>
> For an example, here's the setup work I had to do to check to see if a
> given template type has a member function with a certain name:
>
That is way too complicated, and amounts to a straw man argument. The ugly
code is so because it defines a macro to handle any potential function,
uses an outdated SFINAE idiom, and has a poorly-fitting interface. Here's
an alternative I just threw together with little loss of generality:
#define MAKE_MEMBER_CALL_TRAIT( TRAIT_NAME, FN_NAME, ... ) \
template< typename t, typename converts_to = void, typename = void > \
struct TRAIT_NAME : std::false_type {}; /* Default specialization =
invalid call expression */ \
\
template< typename t, typename converts_to > /* Constrained
specialization used if expression is valid */ \
struct TRAIT_NAME< t, converts_to, \
decltype(void( static_cast< converts_to >( /* Convert to x, or by
default no check due to void */ \
std::declval< t & >().FN_NAME( __VA_ARGS__ ) ) )) > /* Pass
given arguments */ \
: std::true_type {};
MAKE_MEMBER_CALL_TRAIT( fooable, foo, 1, 2, nullptr )
struct a { void foo( int, int, void * ); };
static_assert ( fooable< a >::value, "fooable" );
static_assert ( ! fooable< int >::value, "not fooable" );
But this is way too general. Your subsequent examples don't attempt to
handle any overload generically. Supposing we actually want a trait, this
would be a better comparison.
template< typename t, typename = void >
struct has_character : std::false_type {};
template< typename t >
struct has_character< t, decltype(void( std::declval< t & >().Character( std
::uint8_t(), 0, 0 ) )) >
: std::true_type {};
template< typename t >
typename std::enable_if< has_character< t >::value, bool >::type
ForwardCharacter( std::uint8_t key, int a, int b ) { ... }
template< typename t >
typename std::enable_if< ! has_character< t >::value, bool >::type
ForwardCharacter( std::uint8_t key, int a, int b ) {}
There's really no need for a trait if we're just overloading this one
function.
template< typename t >
// Succeed (evaluate to true and use this overload) if the call expression
is valid.
typename std::enable_if< ( void( std::declval< t & >().Character( std::
uint8_t(), 0, 0 ) ), true),
bool >::type
ForwardCharacter( std::uint8_t key, int a, int b ) { ... }
bool ForwardCharacter( ... ) { return false; }
But given that one of the functions is nearly empty and there are no
dependent expressions in the other, it would be simpler to use a constant
condition and let dead code elimination take care of "overloading." Indeed
given the trait, there's no need for static_if in this case at all.
template< typename t >
bool ForwardCharacter( std::uint8_t key, int a, int b ) {
if ( has_character< t >::value ) return ... ;
else return false;
}
Perhaps educational resources are lagging, but people tend to make C++
metaprogramming harder than it is. Also, the kind of person who allows
things to get too complicated (e.g., deciding to do metaprogramming in the
first place) is likely to get shot in the foot while trying to make a
template perform computation.
In my experience, the problem isn't the basic syntax but the multitude of
ways things can fail due to the intricacy of the C++ type system. For
example, sometimes lvalues map to references, sometimes not. Or, this
template wants to be parameterized over templates; does any potential
argument have a non-type parameter?
Redesigning the language to lower the first step, when the second step is
the tall one, won't fix anything. Concepts are designed mainly to help
type-checking, and looking nice is just a side effect. I've not read up on
static_if, but if it helps the user defer stating their invariants (such as
by concepts), by making the program easier to write intuitively, then it's
just setting up a trap to spring when an unexpected type comes along.
Many languages have set out to satisfy what syntax the customer wants to
see, and few have been any good as a result, because syntax examples are
simple but programs are complicated. Let's work on setting up a safe
framework to work with, because there's no way to defang C++ of its corner
cases.
(As an incidental cautionary tale, I've had a great deal of trouble even
posting this because Google Groups keeps crashing with an undefined
identifier in some machine-generated, probably metaprogrammed, JavaScript.)
--
---
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_22_11383612.1376025997767
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, August 9, 2013 9:28:56 AM UTC+8, Nicol =
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">2=
:
Actually implementing the code for such a type is an absolute nightmare
of Godawful code, particularly with regard to optional functions.=20
std::enable_if is an absolute atrocity, used only because it <i>works</i>,
not because it is in any way reasonable. Something as simple as=20
checking if a type has a particular member function requires a=20
monstrosity of code.<br><div><br>For an example, here's the setup work I
had to do to check to see if a given template type has a member=20
function with a certain name:<br></div></div></blockquote><br>That=20
is way too complicated, and amounts to a straw man argument. The ugly=20
code is so because it defines a macro to handle any potential function,=20
uses an outdated SFINAE idiom, and has a poorly-fitting interface.=20
Here's an alternative I just threw together with little loss of=20
generality:<br><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: #800;" class=3D"styled-by-pre=
ttify">#define</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> MAKE_MEMBER_CALL_TRAIT</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> TRAIT_NAME</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
FN_NAME</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: #660;" class=3D"styled-by-prettify">...</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #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: #000;" class=3D"styled-b=
y-prettify"><br> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> converts_to </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</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">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">void</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"> </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">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> TRAIT_NAME </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">false_type </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: #800;" class=3D"styled-by-prettify">/* Default s=
pecialization =3D invalid call expression */</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">\</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">\</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=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">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> converts_to </span><=
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: #800;" class=3D"styled-by-prettify">/* Constrained specialization use=
d if expression is valid */</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-prettify"><=
br> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> TRAIT_NAME</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> converts_to</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #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">decltype</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</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">static_cast</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> converts_to </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">>(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">/* Convert to x, or by default no check due to void */</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"><br> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">declval</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> t </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">>().</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">FN_NAME</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> __VA_ARGS__ </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">/* Pass given arguments */</span><span style=3D"co=
lor: #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><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">true_type </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br>MAKE_MEMBER_CALL_TRAIT</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> fooable</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-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=
"> </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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">2</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"style=
d-by-prettify">nullptr</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><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</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">int</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">static_assert</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> fooable</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">>::</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"fooable"=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">static_assert</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"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">!</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> fooable</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">>::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">value</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;" cla=
ss=3D"styled-by-prettify">"not fooable"</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-b=
y-prettify"><br></span></div></code></div><br>But
this is way too general. Your subsequent examples don't attempt to=20
handle any overload generically. Supposing we actually want a trait,=20
this would be a better comparison.<br><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: #008;=
" class=3D"styled-by-prettify">template</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"style=
d-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">void</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"><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> has_character </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">false_type </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=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">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> has_character</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> t</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">decltype</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">declval</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> t </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>().</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Character</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">uint8_t</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">0</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">0</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #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"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><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"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">true_t=
ype </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">template</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">typename</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">enable_if</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> has_character</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">>::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</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">bool</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">>::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">type<br></span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">ForwardCharacter</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"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">uint8_t key</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</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: #000;" clas=
s=3D"styled-by-prettify"> b </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">template</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> t </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">typena=
me</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">enable_if</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: #000;" =
class=3D"styled-by-prettify"> has_character</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">>::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">value</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">bool</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">>::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">type<br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">ForwardCharacter</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">uint8_t key</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"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> a</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">int</span><span st=
yle=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: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br>There's really no need f=
or a trait if we're just overloading this one function.<br><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">template</span><span s=
tyle=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">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>// Succeed (evaluate to true and use this overl=
oad) if the call expression is valid.<br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">typename</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">enable_if</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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"><code class=3D"pre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</s=
pan><span class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> std</span><span class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">declval=
</span><span class=3D"styled-by-prettify"><</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> t </span><span class=3D"styled-by-pret=
tify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span class=3D"styled-by-prettify">>().</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Character</span><span class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> std</span><span class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">uint8_t</span><span 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-prett=
ify">0</span><span class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">0</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span class=
=3D"styled-by-prettify">)</span><span class=3D"styled-by-prettify">, true</=
span></code>),</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">type<br=
></span><span style=3D"color: #606;" class=3D"styled-by-prettify">ForwardCh=
aracter</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">uint8_t key</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</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: #000;" clas=
s=3D"styled-by-prettify"> a</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b </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: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...</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-prettify"><=
br></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify"> ForwardCharacter</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> ...</span><span style=3D"co=
lor: #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"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{ return false; }</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>But
given that one of the functions is nearly empty and there are no=20
dependent expressions in the other, it would be simpler to use a=20
constant condition and let dead code elimination take care of=20
"overloading." Indeed given the trait, there's no need for static_if in=20
this case at all.<br> <code class=3D"prettyprint"><div class=3D"pretty=
print" 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"=
color: #008;" class=3D"styled-by-prettify">template</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">ForwardCha=
racter</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">uint8_t key</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> a</span><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: #008;" class=3D"styled-by-prettify">in=
t</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #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"> has_character</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> t </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">value </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">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </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;" clas=
s=3D"styled-by-prettify">else</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">fal=
se</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">}<br></span></div></cod=
e></div><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></=
code><br>Perhaps
educational resources are lagging, but people tend to make C++=20
metaprogramming harder than it is. Also, the kind of person who allows=20
things to get too complicated (e.g., deciding to do metaprogramming in=20
the first place) is likely to get shot in the foot while trying to make a
template perform computation.<br><br>In
my experience, the problem isn't the basic syntax but the multitude of=20
ways things can fail due to the intricacy of the C++ type system. For=20
example, sometimes lvalues map to references, sometimes not. Or, this=20
template wants to be parameterized over templates; does any potential=20
argument have a non-type parameter?<br><br>Redesigning the language to=20
lower the first step, when the second step is the tall one, won't fix=20
anything. Concepts are designed mainly to help type-checking, and=20
looking nice is just a side effect. I've not read up on static_if, but=20
if it helps the user defer stating their invariants (such as by=20
concepts), by making the program easier to write intuitively, then it's=20
just setting up a trap to spring when an unexpected type comes along.<br><b=
r>Many
languages have set out to satisfy what syntax the customer wants to=20
see, and few have been any good as a result, because syntax examples are
simple but programs are complicated. Let's work on setting up a safe=20
framework to work with, because there's no way to defang C++ of its=20
corner cases.<br><br>(As an incidental cautionary tale, I've had a great
deal of trouble even posting this because Google Groups keeps crashing=20
with an undefined identifier in some machine-generated, probably=20
metaprogrammed, JavaScript.)<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_22_11383612.1376025997767--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Aug 2013 23:05:16 -0700 (PDT)
Raw View
------=_Part_299_16103747.1376028316068
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 8, 2013 9:45:41 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 8 August 2013 22:28, Alex B <deva...@gmail.com <javascript:>> wrote:
>
>>
>> How does this differ from regular if statements?
>>>
>>> That is part of my point: that it should pretty much be used in contexts
>> similar to regular if statements. The only difference would be that the
>> unchosen branches would not be compiled.
>>
>
> Why doesn't normal if and optimization take care of this? This sounds
> like a non-problem.
>
Static_if actively prevents compilation of *either* code block until the
condition can be resolved. Optimization simply removes code after it's been
generated. It must still be *legal code*, whereas static_if allows you to
put code that wouldn't be legal there.
Or to put it another way, David's final suggestion (when it's actually
filled in) would fail:
template< typename t >
bool ForwardCharacter( std::uint8_t key, int a, int b ) {
if ( has_character< t >::value )
return m_pApp->Character(key, x, y);
else
return false;
}
This fails to compile because `m_pApp` (which is of type `t`) may *or may
not* have a function called `Character`. That's the entire point of the
test: if that function exists with the expected signature, I want to call
it. If it doesn't, then I don't want to.
You cannot do that with a regular if.
--
---
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_299_16103747.1376028316068
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 8, 2013 9:45:41 PM UTC-7, Nevi=
n ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 8 Augus=
t 2013 22:28, Alex B <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"odG4BaTt0zEJ">deva...@gmail.com</a>>=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div dir=3D"ltr"><br><div><div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"auto"><div>How does this differ from regular if statements?</di=
v></div><div><div>
<p></p></div></div></blockquote></div></div>That is part of my point: that =
it should pretty much be used in contexts similar to regular if statements.=
The only difference would be that the unchosen branches would not be compi=
led.</div>
</div></blockquote><div><br></div><div>Why doesn't normal if and optimizati=
on take care of this? This sounds like a non-problem.</div></div></bl=
ockquote><div><br>Static_if actively prevents compilation of <i>either</i> =
code block until the condition can be resolved. Optimization simply removes=
code after it's been generated. It must still be <i>legal code</i>, wherea=
s static_if allows you to put code that wouldn't be legal there.<br><br>Or =
to put it another way, David's final suggestion (when it's actually filled =
in) would fail:<br><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"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typena=
me</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">ForwardCharacter</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">uint8_t key</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> b </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</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-prettify">=
<br> </span><span style=3D"color: #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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> has_character</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> t </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">>::</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify">value </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> m_pApp</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">-></span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Character</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">key</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> y</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">else</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">false</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div><br>This fails to compile because `m_pApp` (whic=
h is of type `t`) may <i>or may not</i> have a function called `Character`.=
That's the entire point of the test: if that function exists with the expe=
cted signature, I want to call it. If it doesn't, then I don't want to.<br>=
<br>You cannot do that with a regular if.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_299_16103747.1376028316068--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 9 Aug 2013 01:19:44 -0500
Raw View
--047d7b6771161d462f04e37dc5ae
Content-Type: text/plain; charset=ISO-8859-1
On 9 August 2013 01:05, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> It must still be *legal code*, whereas static_if allows you to put code
> that wouldn't be legal there.
>
As was brought up in Kona, if it is not legal code, how do you know when
the code block ends? It sure sounds like it's just another syntax for
macros.
You cannot do that with a regular if.
>
That's the wrong question. Given the timeframes involved (you wouldn't see
static if until at least C++17, if not later), can you do it with concepts
lite?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b6771161d462f04e37dc5ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 9 August 2013 01:05, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br>=A0It must still be <i>legal code</i>, whereas static_=
if allows you to put code that wouldn't be legal there.<br></div></bloc=
kquote><div><br></div><div>As was brought up in Kona, if it is not legal co=
de, how do you know when the code block ends? =A0It sure sounds like it'=
;s just another syntax for macros.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>You can=
not do that with a regular if.<br></div></div></blockquote><div><br></div><=
div>
That's the wrong question. =A0Given the timeframes involved (you wouldn=
't see static if until at least C++17, if not later), can you do it wit=
h concepts lite?</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>>=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b6771161d462f04e37dc5ae--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Aug 2013 23:23:30 -0700 (PDT)
Raw View
------=_Part_290_27198429.1376029410902
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 8, 2013 10:26:37 PM UTC-7, David Krauss wrote:
>
> template< typename t >
> // Succeed (evaluate to true and use this overload) if the call expression
> is valid.
> typename std::enable_if< ( void( std::declval< t & >().Character( std::
> uint8_t(), 0, 0 ) ), true),
> bool >::type
> ForwardCharacter( std::uint8_t key, int a, int b ) { ... }
>
> bool ForwardCharacter( ... ) { return false; }
>
>
That's no more legible than the way I did it.
Perhaps educational resources are lagging, but people tend to make C++
> metaprogramming harder than it is. Also, the kind of person who allows
> things to get too complicated (e.g., deciding to do metaprogramming in the
> first place) is likely to get shot in the foot while trying to make a
> template perform computation.
>
Um, no. What you posted is not reasonable code that is easily digestible.
It's a pile of `declval`, `decltype`, and a mishmash of other stuff that
makes it difficult to know what the hell's going on. This syntax obfuscates
the code so much that finding basic information about the function is made
a chore. What's the function name there? Where's the actual *return type*?
Can it be done? Yes. Is it obvious to anyone who's not already used to it?
Absolutely not. If you can't have an intuitive grasp on this code, then
it's basically a second language artificially bolted on top of the main
one. This is not easily digestible code, so don't act like it is.
Educational resources aren't lagging; this is simply code that most people
don't *want* to read or write.
In my experience, the problem isn't the basic syntax but the multitude of
> ways things can fail due to the intricacy of the C++ type system. For
> example, sometimes lvalues map to references, sometimes not. Or, this
> template wants to be parameterized over templates; does any potential
> argument have a non-type parameter?
>
Passing templates around as template parameters is getting into hardcore
metaprogramming. I focused on simpler metaprograms because those are the
kind of things that people *want* to do, but cannot do in a reasonable
fashion now.
--
---
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_290_27198429.1376029410902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 8, 2013 10:26:37 PM UTC-7, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div =
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code><div><span st=
yle=3D"color:#008">template</span><span style=3D"color:#660"><</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">typename</span><=
span style=3D"color:#000"> t </span><span style=3D"color:#660">></span><=
span style=3D"color:#000"><br>// Succeed (evaluate to true and use this ove=
rload) if the call expression is valid.<br></span><span style=3D"color:#008=
">typename</span><span style=3D"color:#000"> std</span><span style=3D"color=
:#660">::</span><span style=3D"color:#000">enable_if</span><span style=3D"c=
olor:#660"><</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">(</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60"><code><span style=3D"color:#008">void</span><span>(</span><span style=
=3D"color:#000"> std</span><span>::</span><span style=3D"color:#000">declva=
l</span><span><</span><span style=3D"color:#000"> t </span><span>&</=
span><span style=3D"color:#000"> </span><span>>().</span><span style=3D"=
color:#606">Character</span><span>(</span><span style=3D"color:#000"> std</=
span><span>::</span><span style=3D"color:#000">uint8_t</span><span>(),</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><sp=
an>,</span><span style=3D"color:#000"> </span><span style=3D"color:#066">0<=
/span><span style=3D"color:#000"> </span><span>)</span><span style=3D"color=
:#000"> </span><span>)</span><span>, true</span></code>),</span><span style=
=3D"color:#000"><br> </span><span style=3D"color:#008">bool</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">>::</s=
pan><span style=3D"color:#000">type<br></span><span style=3D"color:#606">Fo=
rwardCharacter</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"color=
:#000">uint8_t key</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">int</span><span style=3D"col=
or:#000"> a</span><span style=3D"color:#660">,</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">int</span><span style=3D"color:#000=
"> b </span><span style=3D"color:#660">)</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">...</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">}</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#008">bool</span><s=
pan style=3D"color:#000"></span><span style=3D"color:#606"> ForwardCharacte=
r</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> ...<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">)</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">{ return fal=
se; }</span><span style=3D"color:#000"><br></span></div></code></div><br></=
div></blockquote><div><br>That's no more legible than the way I did it.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Pe=
rhaps
educational resources are lagging, but people tend to make C++=20
metaprogramming harder than it is. Also, the kind of person who allows=20
things to get too complicated (e.g., deciding to do metaprogramming in=20
the first place) is likely to get shot in the foot while trying to make a
template perform computation.<br></div></blockquote><div dir=3D"ltr"><br>U=
m, no. What you posted is not reasonable code that is easily digestible. It=
's a pile of `declval`, `decltype`, and a mishmash of other stuff that make=
s it difficult to know what the hell's going on. This syntax obfuscates the=
code so much that finding basic information about the function is made a c=
hore. What's the function name there? Where's the actual <i>return type</i>=
?<br></div><div dir=3D"ltr"> <br>Can it be done? Yes. Is it obvious to=
anyone who's not already used to it? Absolutely not. If you can't have an =
intuitive grasp on this code, then it's basically a second language artific=
ially bolted on top of the main one. This is not easily digestible code, so=
don't act like it is. Educational resources aren't lagging; this is simply=
code that most people don't <i>want</i> to read or write.<br><br></div><bl=
ockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div dir=3D"ltr">In
my experience, the problem isn't the basic syntax but the multitude of=20
ways things can fail due to the intricacy of the C++ type system. For=20
example, sometimes lvalues map to references, sometimes not. Or, this=20
template wants to be parameterized over templates; does any potential=20
argument have a non-type parameter?<br></div></blockquote><div><br>Passing =
templates around as template parameters is getting into hardcore metaprogra=
mming. I focused on simpler metaprograms because those are the kind of thin=
gs that people <i>want</i> to do, but cannot do in a reasonable fashion now=
..</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_290_27198429.1376029410902--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 8 Aug 2013 23:30:32 -0700 (PDT)
Raw View
------=_Part_285_32760509.1376029832395
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 8, 2013 11:19:44 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 9 August 2013 01:05, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>> It must still be *legal code*, whereas static_if allows you to put code
>> that wouldn't be legal there.
>>
>
> As was brought up in Kona, if it is not legal code, how do you know when
> the code block ends? It sure sounds like it's just another syntax for
> macros.
>
That was stated in the static_if paper: you have to do some basic lexical
analysis, effectively storing an arbitrary list of tokens until you've
matched the curly braces.
> You cannot do that with a regular if.
>>
>
> That's the wrong question.
>
That's... not a question.
> Given the timeframes involved (you wouldn't see static if until at least
> C++17, if not later), can you do it with concepts lite?
>
You seem to be missing the point of the thread. Concepts lite cannot do
this; you can only create additional function overloads with it. And
computation-by-function-overload is effectively a form of declarative
programming, which is what the thread is saying we should *avoid*.
I agree about the practical issues of timescale and implement-ability. But
you can't deny that this furthers the notion of metaprogramming being this
entire other thing that requires a different way of solving problems,
compared to doing things the more natural imperative programming way.
"Perfect is the enemy of good" is often trotted out as a way to disparage
trying to find a better solution than one that merely works. But I remind
you that the current horrific state of metaprogramming exists *precisely
because* people focused on "good" rather than "perfect" (though
technically, its because they focused on "working"). It is that which has
caused this rift between "C++ programmers who understand metaprogramming"
and "most C++ programmers".
C++ needs more "perfect" and less "good enough". A little idealism and
vision never hurt.
--
---
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_285_32760509.1376029832395
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 8, 2013 11:19:44 PM UTC-7, Nev=
in ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 9 Augu=
st 2013 01:05, Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"87BNiNUr7OkJ">jmck...@gmail.com</a=
>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div dir=3D"ltr"><br> It must still be <i>legal code</i>, whereas stat=
ic_if allows you to put code that wouldn't be legal there.<br></div></block=
quote><div><br></div><div>As was brought up in Kona, if it is not legal cod=
e, how do you know when the code block ends? It sure sounds like it's=
just another syntax for macros.</div></div></blockquote><div><br>That was =
stated in the static_if paper: you have to do some basic lexical analysis, =
effectively storing an arbitrary list of tokens until you've matched the cu=
rly braces.<br> </div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v 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"><di=
v>You cannot do that with a regular if.<br></div></div></blockquote><div><b=
r></div><div>
That's the wrong question.</div></div></blockquote><div><br>That's... not a=
question.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
class=3D"gmail_quote"><div> Given the timeframes involved (you would=
n't see static if until at least C++17, if not later), can you do it with c=
oncepts lite?</div></div></blockquote><div><br>You seem to be missing the p=
oint of the thread. Concepts lite cannot do this; you can only create addit=
ional function overloads with it. And computation-by-function-overload is e=
ffectively a form of declarative programming, which is what the thread is s=
aying we should <i>avoid</i>.<br><br>I agree about the practical issues of =
timescale and implement-ability. But you can't deny that this furthers the =
notion of metaprogramming being this entire other thing that requires a dif=
ferent way of solving problems, compared to doing things the more natural i=
mperative programming way.<br><br>"Perfect is the enemy of good" is often t=
rotted out as a way to disparage trying to find a better solution than one =
that merely works. But I remind you that the current horrific state of meta=
programming exists <i>precisely because</i> people focused on "good" rather=
than "perfect" (though technically, its because they focused on "working")=
.. It is that which has caused this rift between "C++ programmers who unders=
tand metaprogramming" and "most C++ programmers".<br><br>C++ needs more "pe=
rfect" and less "good enough". A little idealism and vision never hurt.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_285_32760509.1376029832395--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 8 Aug 2013 23:46:19 -0700 (PDT)
Raw View
------=_Part_352_14308964.1376030779639
Content-Type: text/plain; charset=ISO-8859-1
On Friday, August 9, 2013 2:23:30 PM UTC+8, Nicol Bolas wrote:
> Um, no. What you posted is not reasonable code that is easily digestible.
> It's a pile of `declval`, `decltype`, and a mishmash of other stuff that
> makes it difficult to know what the hell's going on. This syntax obfuscates
> the code so much that finding basic information about the function is made
> a chore. What's the function name there? Where's the actual *return type*?
>
What you posted is not only undigestible, but has too many bells and
whistles. It's reasonable, if you can't figure out how to discriminate on
the existence of one member, to attempt to make a tool to discriminate on
the existence of any member, so as not to clutter ForwardCharacter, which
is the problem at hand. But in this case it's not a good factoring of the
problem and complexity explodes.
Knowing how much to bite off at once, and what should or shouldn't be
generalized, is where resources might be lagging/lacking.
> Can it be done? Yes. Is it obvious to anyone who's not already used to it?
> Absolutely not. If you can't have an intuitive grasp on this code, then
> it's basically a second language artificially bolted on top of the main
> one. This is not easily digestible code, so don't act like it is.
> Educational resources aren't lagging; this is simply code that most people
> don't *want* to read or write.
>
Someone with the basic concept that C++ works by disabling functions where
the template argument causes a syntax error, can probably figure it out
given the comments I provided, or if not then with a few more comments and
whitespaces. It's not pretty, but it is idiomatic and the noise can be
filtered out. (Idioms besides mine are valid, but what you used is far more
verbose than necessary.)
Concepts should make it prettier in any case, but static_if doesn't help
because it doesn't address the core problem of encapsulating a syntax
error. Even with static_if you would have to define the trait, which is 99%
of the ugly.
>
> In my experience, the problem isn't the basic syntax but the multitude of
>> ways things can fail due to the intricacy of the C++ type system. For
>> example, sometimes lvalues map to references, sometimes not. Or, this
>> template wants to be parameterized over templates; does any potential
>> argument have a non-type parameter?
>>
>
> Passing templates around as template parameters is getting into hardcore
> metaprogramming. I focused on simpler metaprograms because those are the
> kind of things that people *want* to do, but cannot do in a reasonable
> fashion now.
>
There are plenty of examples. The relation between value category and
reference types bites plenty of newbies. The difference between
specialization and inheritance from a specialized type is another.
I'm not saying metaprogramming is easy, just that it's made harder by the
prevalence of outdated code bases (nobody should still be checking sizeof
yes_type), and the lack of advice about when to define a trait, when to ask
the user to define a trait per the traits idiom, etc.
--
---
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_352_14308964.1376030779639
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Friday, August 9, 2013 2:23:30 PM UTC+8, Nicol Bola=
s wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Um, no. What you posted is not reasonable code that is easily digestibl=
e. It's a pile of `declval`, `decltype`, and a mishmash of other stuff that=
makes it difficult to know what the hell's going on. This syntax obfuscate=
s the code so much that finding basic information about the function is mad=
e a chore. What's the function name there? Where's the actual <i>return typ=
e</i>?</div></div></blockquote><div><br>What you posted is not only undiges=
tible, but has too many bells and whistles. It's reasonable, if you can't f=
igure out how to discriminate on the existence of one member, to attempt to=
make a tool to discriminate on the existence of any member, so as not to c=
lutter ForwardCharacter, which is the problem at hand. But in this case it'=
s not a good factoring of the problem and complexity explodes.<br><br>Knowi=
ng how much to bite off at once, and what should or shouldn't be generalize=
d, is where resources might be lagging/lacking.<br> </div><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"><div dir=3D"ltr">Can it b=
e done? Yes. Is it obvious to anyone who's not already used to it? Absolute=
ly not. If you can't have an intuitive grasp on this code, then it's basica=
lly a second language artificially bolted on top of the main one. This is n=
ot easily digestible code, so don't act like it is. Educational resources a=
ren't lagging; this is simply code that most people don't <i>want</i> to re=
ad or write.<br></div></div></blockquote><div><br>Someone with the basic co=
ncept that C++ works by disabling functions where the template argument cau=
ses a syntax error, can probably figure it out given the comments I provide=
d, or if not then with a few more comments and whitespaces. It's not pretty=
, but it is idiomatic and the noise can be filtered out. (Idioms besides mi=
ne are valid, but what you used is far more verbose than necessary.)<br><br=
>Concepts should make it prettier in any case, but static_if doesn't help b=
ecause it doesn't address the core problem of encapsulating a syntax error.=
Even with static_if you would have to define the trait, which is 99% of th=
e ugly.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div dir=3D"ltr"><br></div><blockquote style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"g=
mail_quote"><div dir=3D"ltr">In
my experience, the problem isn't the basic syntax but the multitude of=20
ways things can fail due to the intricacy of the C++ type system. For=20
example, sometimes lvalues map to references, sometimes not. Or, this=20
template wants to be parameterized over templates; does any potential=20
argument have a non-type parameter?<br></div></blockquote><div><br>Passing =
templates around as template parameters is getting into hardcore metaprogra=
mming. I focused on simpler metaprograms because those are the kind of thin=
gs that people <i>want</i> to do, but cannot do in a reasonable fashion now=
..</div></div></blockquote><div><br>There are plenty of examples. The relati=
on between value category and reference types bites plenty of newbies. The =
difference between specialization and inheritance from a specialized type i=
s another.<br><br>I'm not saying metaprogramming is easy, just that it's ma=
de harder by the prevalence of outdated code bases (nobody should still be =
checking sizeof yes_type), and the lack of advice about when to define a tr=
ait, when to ask the user to define a trait per the traits idiom, etc.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_352_14308964.1376030779639--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 9 Aug 2013 01:53:59 -0500
Raw View
--047d7bdc88f4a116b604e37e3f0d
Content-Type: text/plain; charset=ISO-8859-1
On 9 August 2013 01:30, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> You seem to be missing the point of the thread. Concepts lite cannot do
> this; you can only create additional function overloads with it. And
> computation-by-function-overload is effectively a form of declarative
> programming, which is what the thread is saying we should *avoid*.
>
Because apparently people don't like to use declarative mechanisms like
overloaded functions, virtual functions, etc.
> I agree about the practical issues of timescale and implement-ability.
>
This is supposed to be a group about proposals, after all.
> But you can't deny that this furthers the notion of metaprogramming being
> this entire other thing that requires a different way of solving problems,
> compared to doing things the more natural imperative programming way.
>
That's your theory.
Of course, many people think it's good C++ when 90%+ of your code
uses defaulted copy/move constructors/assignment operators, defaulted
destructors, etc. But those are all declarative.
And the reason you implement things like smart pointers and other RAII
types is so that you can use them declaratively.
"Perfect is the enemy of good" is often trotted out as a way to disparage
> trying to find a better solution than one that merely works. But I remind
> you that the current horrific state of metaprogramming exists *precisely
> because* people focused on "good" rather than "perfect" (though
> technically, its because they focused on "working"). It is that which has
> caused this rift between "C++ programmers who understand metaprogramming"
> and "most C++ programmers".
>
> C++ needs more "perfect" and less "good enough". A little idealism and
> vision never hurt.
>
Okay. Let's revisit static if when it is "perfect". :-)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bdc88f4a116b604e37e3f0d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 9 August 2013 01:30, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto=
:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br>You seem to be missing the point of the thread. Concep=
ts lite cannot do this; you can only create additional function overloads w=
ith it. And computation-by-function-overload is effectively a form of decla=
rative programming, which is what the thread is saying we should <i>avoid</=
i>.<br>
</div></blockquote><div><br></div><div>Because apparently people don't =
like to use declarative mechanisms like overloaded functions, virtual funct=
ions, etc.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I agree about the practical issues of timescale and i=
mplement-ability.</div></div></blockquote><div><br></div><div>This is suppo=
sed to be a group about proposals, after all.</div><div>=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr"><div> But you can't deny that this furthers the notion=
of metaprogramming being this entire other thing that requires a different=
way of solving problems, compared to doing things the more natural imperat=
ive programming way.<br>
</div></div></blockquote><div><br></div><div>That's your theory.</div><=
div><br></div><div>Of course, many people think it's good C++ when 90%+=
of your code uses=A0defaulted copy/move constructors/assignment operators,=
defaulted destructors, etc. =A0But those are all declarative.</div>
<div><br></div><div>And the reason you implement things like smart pointers=
and other RAII types is so that you can use them declaratively.</div><div>=
<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"><div>"Perfect is the enemy of good" is often tro=
tted out as a way to disparage trying to find a better solution than one th=
at merely works. But I remind you that the current horrific state of metapr=
ogramming exists <i>precisely because</i> people focused on "good"=
; rather than "perfect" (though technically, its because they foc=
used on "working"). It is that which has caused this rift between=
"C++ programmers who understand metaprogramming" and "most =
C++ programmers".<br>
<br>C++ needs more "perfect" and less "good enough". A =
little idealism and vision never hurt.<br></div></div></blockquote><div><br=
></div><div>Okay. =A0Let's revisit static if when it is "perfect&q=
uot;. :-)</div>
<div>--=A0</div></div>=A0Nevin ":-)" Liber=A0 <mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>>=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bdc88f4a116b604e37e3f0d--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 9 Aug 2013 10:24:41 +0300
Raw View
--001a11c22780059da604e37eab33
Content-Type: text/plain; charset=ISO-8859-1
On 9 August 2013 09:53, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 9 August 2013 01:30, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>> You seem to be missing the point of the thread. Concepts lite cannot do
>> this; you can only create additional function overloads with it. And
>> computation-by-function-overload is effectively a form of declarative
>> programming, which is what the thread is saying we should *avoid*.
>>
>
> Because apparently people don't like to use declarative mechanisms like
> overloaded functions, virtual functions, etc.
>
FWIW, "people" probably don't like being _forced_ to write multiple
overloads when they can use an if statement,
if it suits the problem at hand better. That's mostly the beef with the
desire of having function-local static ifs.
Concepts lite still offers just one way, which is multiple constrained
overloads.
But you can't deny that this furthers the notion of metaprogramming being
this entire other thing that requires a different way of solving problems,
compared to doing things the more natural imperative programming way.
>
> That's your theory.
>
I think there's some amounts of evidence for that theory. Decreasing the
difference in the programming models
between metaprograms and programs would very likely be a good thing.
>
>
> C++ needs more "perfect" and less "good enough". A little idealism and
>> vision never hurt.
>>
>
> Okay. Let's revisit static if when it is "perfect". :-)
>
>
>
Suits me, too. Perfect solutions have the slight problem that they never
ship. I'll throw static if
under the bus in a heartbeat if I can get concepts lite in a short
timeframe, because as imperfect
as it may be, it solves the vast majority of the current problems, and I
can live with multiple
overloads, especially if the alternative would be waiting for a "perfect"
solution.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c22780059da604e37eab33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 August 2013 09:53, Nevin Liber <span dir=3D"ltr"><<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.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 class=3D"im">On 9 August 2013 01:30, Ni=
col Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" targ=
et=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br>
</div><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div dir=3D"ltr"><br>You seem to be missing the point of the thread. Concep=
ts lite cannot do this; you can only create additional function overloads w=
ith it. And computation-by-function-overload is effectively a form of decla=
rative programming, which is what the thread is saying we should <i>avoid</=
i>.<br>
</div></blockquote><div><br></div></div><div>Because apparently people don&=
#39;t like to use declarative mechanisms like overloaded functions, virtual=
functions, etc.</div></div></blockquote><div><br></div><div>FWIW, "pe=
ople" probably don't like being _forced_ to write multiple overloa=
ds when they can use an if statement,<br>
</div><div>if it suits the problem at hand better. That's mostly the be=
ef with the desire of having function-local static ifs.<br></div><div>Conce=
pts lite still offers just one way, which is multiple constrained overloads=
..<br>
<br></div><br><div dir=3D"ltr"><div>But you can't deny that this furthe=
rs the notion of metaprogramming being this entire other thing that require=
s a different way of solving problems, compared to doing things the more na=
tural imperative programming way.<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div =
class=3D"im"><div><br></div></div><div>That's your theory.</div></div><=
/blockquote>
<div><br></div><div>I think there's some amounts of evidence for that t=
heory. Decreasing the difference in the programming models<br>between metap=
rograms and programs would very likely be a good thing.<br><br>=A0<br></div=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div><br></div><b=
r><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>C++ needs more "perfect" and less "goo=
d enough". A little idealism and vision never hurt.<br></div></div></b=
lockquote><div><br></div></div><div>Okay. =A0Let's revisit static if wh=
en it is "perfect". :-)</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br><br></div></font></span></div></blockquote><div><br></div><div>Sui=
ts me, too. Perfect solutions have the slight problem that they never ship.=
I'll throw static if<br>under the bus in a heartbeat if I can get conc=
epts lite in a short timeframe, because as imperfect<br>
as it may be, it solves the vast majority of the current problems, and I ca=
n live with multiple<br>overloads, especially if the alternative would be w=
aiting for a "perfect" solution.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c22780059da604e37eab33--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 9 Aug 2013 00:35:34 -0700 (PDT)
Raw View
------=_Part_349_361734.1376033734292
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 8, 2013 11:46:19 PM UTC-7, David Krauss wrote:
>
> On Friday, August 9, 2013 2:23:30 PM UTC+8, Nicol Bolas wrote:
>
>> Um, no. What you posted is not reasonable code that is easily digestible.
>> It's a pile of `declval`, `decltype`, and a mishmash of other stuff that
>> makes it difficult to know what the hell's going on. This syntax obfuscates
>> the code so much that finding basic information about the function is made
>> a chore. What's the function name there? Where's the actual *return type*
>> ?
>>
>
> What you posted is not only undigestible, but has too many bells and
> whistles. It's reasonable, if you can't figure out how to discriminate on
> the existence of one member, to attempt to make a tool to discriminate on
> the existence of any member, so as not to clutter ForwardCharacter, which
> is the problem at hand. But in this case it's not a good factoring of the
> problem and complexity explodes.
>
> Knowing how much to bite off at once, and what should or shouldn't be
> generalized, is where resources might be lagging/lacking.
>
I think you're trying to read far too much into a simple example. But if
you want more details, there was more than one such function in the
original file. As I said, it was part of a template class that the user
provides a class that is expected to implement certain interfaces. Some of
those interfaces are optional, so every optional interface needed a
forwarding function like that. Which meant each one needed a means to
detect if the function in question was available.
So I needed a general solution that could be applied to many such
functions. It also needed to be C++98/03 compatible, because not everyone
has the latest compilers (the original code used a home-grown equivalent to
std::enable_if).
Can it be done? Yes. Is it obvious to anyone who's not already used to it?
>> Absolutely not. If you can't have an intuitive grasp on this code, then
>> it's basically a second language artificially bolted on top of the main
>> one. This is not easily digestible code, so don't act like it is.
>> Educational resources aren't lagging; this is simply code that most people
>> don't *want* to read or write.
>>
>
> Someone with the basic concept that C++ works by disabling functions where
> the template argument causes a syntax error, can probably figure it out
> given the comments I provided, or if not then with a few more comments and
> whitespaces. It's not pretty, but it is idiomatic and the noise can be
> filtered out. (Idioms besides mine are valid, but what you used is far more
> verbose than necessary.)
>
And that's really the big issue with this sort of metaprogramming. SFINAE
is not a "basic concept" of C++. It's not something you can look up in the
standard. It's a *hack*. It cannot be learned from first principles or just
from a cursory examination of the language. It must be taught idiomatically.
That's what static if and concepts lite both have in common: they make *
explicit* what SFINAE was doing implicitly. They turn an idiom into a
language feature. Much like deriving from boost::noncopyable was an idiom,
but now we have the language feature = delete which not only covers
non-copyable, but handles much more. The = delete syntax is more effective
at explaining the problem, guarantees a compile-time error rather than a
link-time one, and provides a far more reasonable error message when it
happens.
Until something stops being a hack and starts begin a real feature, you're
not going to get many non-experts using it. Regular users use explicit
language features; experts use hacks.
Even moreso if the library idiom in question is "not pretty". That is a
large part of the reason why people don't use metaprogramming. Code needs
to be legible in order to be maintainable, and metaprogramming is only
legible to people who are already steeped in its lore. It's like another
language with its own bizarre and very verbose idioms and lots of "noise"
that must be "filtered out" before you can understand what's going on.
Why would a relatively inexperienced user of C++ bother learning something
like that? It's just too much complexity, with a lot of noise and little
substance to it. Improve the signal-to-noise ratio of metaprogramming, and
you're *far* more likely to get people to start using it. Give it a real
basis in the language rather than a hack, and again, you're more likely to
get people using it. Remove its idiomatic nature, so rather than a
half-dozen ways of using it, there's one obvious and correct way to
implement it, and you will again improve the uptake of people using it.
Concepts should make it prettier in any case, but static_if doesn't help
> because it doesn't address the core problem of encapsulating a syntax
> error. Even with static_if you would have to define the trait, which is 99%
> of the ugly.
>
No; 99% of the ugly is that the enable_if syntax confuses the function
signature to the point that you can barely tell it's even declaring a
function.
--
---
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_349_361734.1376033734292
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 8, 2013 11:46:19 PM UTC-7, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Fr=
iday, August 9, 2013 2:23:30 PM UTC+8, Nicol Bolas wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>Um, no. What you posted is =
not reasonable code that is easily digestible. It's a pile of `declval`, `d=
ecltype`, and a mishmash of other stuff that makes it difficult to know wha=
t the hell's going on. This syntax obfuscates the code so much that finding=
basic information about the function is made a chore. What's the function =
name there? Where's the actual <i>return type</i>?</div></div></blockquote>=
<div><br>What you posted is not only undigestible, but has too many bells a=
nd whistles. It's reasonable, if you can't figure out how to discriminate o=
n the existence of one member, to attempt to make a tool to discriminate on=
the existence of any member, so as not to clutter ForwardCharacter, which =
is the problem at hand. But in this case it's not a good factoring of the p=
roblem and complexity explodes.<br><br>Knowing how much to bite off at once=
, and what should or shouldn't be generalized, is where resources might be =
lagging/lacking.</div></div></blockquote><div><br>I think you're trying to =
read far too much into a simple example. But if you want more details, ther=
e was more than one such function in the original file. As I said, it was p=
art of a template class that the user provides a class that is expected to =
implement certain interfaces. Some of those interfaces are optional, so eve=
ry optional interface needed a forwarding function like that. Which meant e=
ach one needed a means to detect if the function in question was available.=
<br><br>So I needed a general solution that could be applied to many such f=
unctions. It also needed to be C++98/03 compatible, because not everyone ha=
s the latest compilers (the original code used a home-grown equivalent to s=
td::enable_if).<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv dir=3D"ltr">Can it be done? Yes. Is it obvious to anyone who's not alrea=
dy used to it? Absolutely not. If you can't have an intuitive grasp on this=
code, then it's basically a second language artificially bolted on top of =
the main one. This is not easily digestible code, so don't act like it is. =
Educational resources aren't lagging; this is simply code that most people =
don't <i>want</i> to read or write.<br></div></div></blockquote><div><br>So=
meone with the basic concept that C++ works by disabling functions where th=
e template argument causes a syntax error, can probably figure it out given=
the comments I provided, or if not then with a few more comments and white=
spaces. It's not pretty, but it is idiomatic and the noise can be filtered =
out. (Idioms besides mine are valid, but what you used is far more verbose =
than necessary.)<br></div></div></blockquote><div><br>And that's really the=
big issue with this sort of metaprogramming. SFINAE is not a "basic concep=
t" of C++. It's not something you can look up in the standard. It's a <i>ha=
ck</i>. It cannot be learned from first principles or just from a cursory e=
xamination of the language. It must be taught idiomatically.<br><br>That's =
what static if and concepts lite both have in common: they make <i>explicit=
</i> what SFINAE was doing implicitly. They turn an idiom into a language f=
eature. Much like deriving from boost::noncopyable was an idiom, but now we=
have the language feature =3D delete which not only covers non-copyable, b=
ut handles much more. The =3D delete syntax is more effective at explaining=
the problem, guarantees a compile-time error rather than a link-time one, =
and provides a far more reasonable error message when it happens.<br><br>Un=
til something stops being a hack and starts begin a real feature, you're no=
t going to get many non-experts using it. Regular users use explicit langua=
ge features; experts use hacks.<br><br>Even moreso if the library idiom in =
question is "not pretty". That is a large part of the reason why people don=
't use metaprogramming. Code needs to be legible in order to be maintainabl=
e, and metaprogramming is only legible to people who are already steeped in=
its lore. It's like another language with its own bizarre and very verbose=
idioms and lots of "noise" that must be "filtered out" before you can unde=
rstand what's going on.<br><br>Why would a relatively inexperienced user of=
C++ bother learning something like that? It's just too much complexity, wi=
th a lot of noise and little substance to it. Improve the signal-to-noise r=
atio of metaprogramming, and you're <i>far</i> more likely to get people to=
start using it. Give it a real basis in the language rather than a hack, a=
nd again, you're more likely to get people using it. Remove its idiomatic n=
ature, so rather than a half-dozen ways of using it, there's one obvious an=
d correct way to implement it, and you will again improve the uptake of peo=
ple using it.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>Concepts should make it prettier in any case, but static=
_if doesn't help because it doesn't address the core problem of encapsulati=
ng a syntax error. Even with static_if you would have to define the trait, =
which is 99% of the ugly.</div></div></blockquote><div><br>No; 99% of the u=
gly is that the enable_if syntax confuses the function signature to the poi=
nt that you can barely tell it's even declaring a function.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_349_361734.1376033734292--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 9 Aug 2013 00:43:21 -0700 (PDT)
Raw View
------=_Part_293_20976933.1376034201683
Content-Type: text/plain; charset=ISO-8859-1
On Friday, August 9, 2013 12:24:41 AM UTC-7, Ville Voutilainen wrote:
>
> Suits me, too. Perfect solutions have the slight problem that they never
> ship. I'll throw static if
> under the bus in a heartbeat if I can get concepts lite in a short
> timeframe, because as imperfect
> as it may be, it solves the vast majority of the current problems, and I
> can live with multiple
> overloads, especially if the alternative would be waiting for a "perfect"
> solution.
>
That's the part I don't understand. Why is this an either/or question *at
all*? As I understand it, the people pushing for static if are not the same
people pushing for concepts lite. So... why not let them develop a static
if technical specification? Why should the standards committee basically so
"Go away until these other guys finish"?
It's not like the networking TS is being affected by the filesystem TS. Why
should a static if TS affect the concepts lite TS?
This sounds more like backroom politicking than good standardization
practice. Concepts was effectively dead before the first lite proposal came
out. The closest thing we had before that was a first-pass of how one might
apply concepts to the standard library, but that was just a thought
experiment, not a proposal. Static if seemed like it was well under way to
becoming something real. And then, within 6 months of the first concepts
lite proposal, static if is cast aside as something that they *might* get
back to at some point, maybe.
What's the reason that static if would take longer to standardize in a TS
than concepts lite anyway?
--
---
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_293_20976933.1376034201683
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 9, 2013 12:24:41 AM UTC-7, Ville Voutila=
inen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div></div><div>Suits me, too. Perfect soluti=
ons have the slight problem that they never ship. I'll throw static if<br>u=
nder the bus in a heartbeat if I can get concepts lite in a short timeframe=
, because as imperfect<br>
as it may be, it solves the vast majority of the current problems, and I ca=
n live with multiple<br>overloads, especially if the alternative would be w=
aiting for a "perfect" solution.</div></div></div></div></blockquote><div><=
br>That's the part I don't understand. Why is this an either/or question <i=
>at all</i>? As I understand it, the people pushing for static if are not t=
he same people pushing for concepts lite. So... why not let them develop a =
static if technical specification? Why should the standards committee basic=
ally so "Go away until these other guys finish"?<br><br>It's not like the n=
etworking TS is being affected by the filesystem TS. Why should a static if=
TS affect the concepts lite TS?<br><br>This sounds more like backroom poli=
ticking than good standardization practice. Concepts was effectively dead b=
efore the first lite proposal came out. The closest thing we had before tha=
t was a first-pass of how one might apply concepts to the standard library,=
but that was just a thought experiment, not a proposal. Static if seemed l=
ike it was well under way to becoming something real. And then, within 6 mo=
nths of the first concepts lite proposal, static if is cast aside as someth=
ing that they <i>might</i> get back to at some point, maybe.<br><br>What's =
the reason that static if would take longer to standardize in a TS than con=
cepts lite anyway?<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_293_20976933.1376034201683--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 9 Aug 2013 10:57:27 +0300
Raw View
--047d7b33d3743b85a304e37f2044
Content-Type: text/plain; charset=ISO-8859-1
On 9 August 2013 10:43, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> That's the part I don't understand. Why is this an either/or question *at
> all*? As I understand it, the people pushing for static if are not the
> same people pushing for concepts lite. So... why not let them develop a
> static if technical specification? Why should the standards committee
> basically so "Go away until these other guys finish"?
>
That's not what the committee is saying. The concepts SG will not take
static if work on their plate, because they don't
think it's a viable design. They can't, however, stop other people from
forming a static if SG if critical mass for such
an SG appears. Thus far it hasn't appeared.
> It's not like the networking TS is being affected by the filesystem TS.
> Why should a static if TS affect the concepts lite TS?
>
> This sounds more like backroom politicking than good standardization
> practice. Concepts was effectively dead before the first lite proposal came
> out. The closest thing we had before that was a first-pass of how one might
> apply concepts to the standard library, but that was just a thought
> experiment, not a proposal. Static if seemed like it was well under way to
> becoming something real. And then, within 6 months of the first concepts
> lite proposal, static if is cast aside as something that they *might* get
> back to at some point, maybe.
>
I guess the concepts lite proposal was published when it was actually
implemented and otherwise ready, so that it didn't
get caught up with endless debates from the get-go.
> What's the reason that static if would take longer to standardize in a TS
> than concepts lite anyway?
>
>
I haven't heard anyone say that concepts are a bad idea, but I have heard a
handful of people say exactly
that about static if. That might end up meaning that static if will take
longer to standardize via any mechanism,
since it might be killed before it gets anywhere near a standard.
--
---
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/.
--047d7b33d3743b85a304e37f2044
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 August 2013 10:43, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
>That's the part I don't understand. Why is this an either/or quest=
ion <i>at all</i>? As I understand it, the people pushing for static if are=
not the same people pushing for concepts lite. So... why not let them deve=
lop a static if technical specification? Why should the standards committee=
basically so "Go away until these other guys finish"?<br>
</div></div></blockquote><div><br></div><div>That's not what the commit=
tee is saying. The concepts SG will not take static if work on their plate,=
because they don't<br>think it's a viable design. They can't, =
however, stop other people from forming a static if SG if critical mass for=
such<br>
an SG appears. Thus far it hasn't appeared. <br>=A0<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br>It=
9;s not like the networking TS is being affected by the filesystem TS. Why =
should a static if TS affect the concepts lite TS?<br>
<br>This sounds more like backroom politicking than good standardization pr=
actice. Concepts was effectively dead before the first lite proposal came o=
ut. The closest thing we had before that was a first-pass of how one might =
apply concepts to the standard library, but that was just a thought experim=
ent, not a proposal. Static if seemed like it was well under way to becomin=
g something real. And then, within 6 months of the first concepts lite prop=
osal, static if is cast aside as something that they <i>might</i> get back =
to at some point, maybe.<br>
</div></div></blockquote><div><br>I guess the concepts lite proposal was pu=
blished when it was actually implemented and otherwise ready, so that it di=
dn't <br>get caught up with endless debates from the get-go. <br><br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv><br>What's the reason that static if would take longer to standardiz=
e in a TS than concepts lite anyway?<br>
</div></div><div class=3D""><div>
<br></div></div></blockquote><div><br></div><div>I haven't heard anyone=
say that concepts are a bad idea, but I have heard a handful of people say=
exactly<br>that about static if. That might end up meaning that static if =
will take longer to standardize via any mechanism,<br>
since it might be killed before it gets anywhere near a standard. <br></div=
></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b33d3743b85a304e37f2044--
.
Author: Alex B <devalexb@gmail.com>
Date: Fri, 9 Aug 2013 14:27:53 -0400
Raw View
--001a11c3cb6cccbaf704e387ee3a
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 9, 2013 at 3:57 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 9 August 2013 10:43, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>> That's the part I don't understand. Why is this an either/or question *at
>> all*? As I understand it, the people pushing for static if are not the
>> same people pushing for concepts lite. So... why not let them develop a
>> static if technical specification? Why should the standards committee
>> basically so "Go away until these other guys finish"?
>>
>
> That's not what the committee is saying. The concepts SG will not take
> static if work on their plate, because they don't
> think it's a viable design. They can't, however, stop other people from
> forming a static if SG if critical mass for such
> an SG appears. Thus far it hasn't appeared.
>
>
Really, a SG just for a "function block static if" proposal?
I think the controversial parts of the N3329 proposal are mostly about
conflicts with concepts. The proposal try to solve some problems that are
better solved by concepts and the 'requires' keyword. (on a side note, it
also seems too confusing/unnatural for people that a static if statement
wouldn't introduce a new scope, even with the usage of {} brace, but this
could easily be revised)
But for usages within a function block, it doesn't get in the way of
concepts at all, so it makes sense like you said to not put it in the plate
of the concepts SG.
But a brand new SG just for it? Why not threat it like any other proposal?
--
---
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/.
--001a11c3cb6cccbaf704e387ee3a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Fri, Aug 9, 2013 at 3:57 AM, Ville Voutilainen <span dir=3D"ltr"><<a =
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutila=
inen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">
<div>On 9 August 2013 10:43, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><br><div>That's the part I don't =
understand. Why is this an either/or question <i>at all</i>? As I understan=
d it, the people pushing for static if are not the same people pushing for =
concepts lite. So... why not let them develop a static if technical specifi=
cation? Why should the standards committee basically so "Go away until=
these other guys finish"?<br>
</div></div></blockquote><div><br></div></div><div>That's not what the =
committee is saying. The concepts SG will not take static if work on their =
plate, because they don't<br>think it's a viable design. They can&#=
39;t, however, stop other people from forming a static if SG if critical ma=
ss for such<br>
an SG appears. Thus far it hasn't appeared. <br>=A0<br></div></div></di=
v></div></blockquote><div><br></div><div>Really, a SG just for a "func=
tion block static if" proposal?</div>
<div><br></div><div>I think the controversial parts of the N3329 proposal a=
re mostly about conflicts with concepts. The proposal try to solve some pro=
blems that are better solved by concepts and the 'requires' keyword=
.. (on a side note, it also seems too confusing/unnatural for people that a =
static if statement wouldn't introduce a new scope, even with the usage=
of {} brace, but this could easily be revised)</div>
<div><br></div><div>But for usages within a function block, it doesn't =
get in the way of concepts at all, so it makes sense like you said to not p=
ut it in the plate of the concepts SG.</div><div><br></div><div>But a brand=
new SG just for it? Why not threat it like any other proposal?</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c3cb6cccbaf704e387ee3a--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 9 Aug 2013 11:36:49 -0700
Raw View
--001a11c2332cc6307704e3880e5e
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 9, 2013 at 11:27 AM, Alex B <devalexb@gmail.com> wrote:
>
> On Fri, Aug 9, 2013 at 3:57 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>>
>>
>> On 9 August 2013 10:43, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>>
>>> That's the part I don't understand. Why is this an either/or question *at
>>> all*? As I understand it, the people pushing for static if are not the
>>> same people pushing for concepts lite. So... why not let them develop a
>>> static if technical specification? Why should the standards committee
>>> basically so "Go away until these other guys finish"?
>>>
>>
>> That's not what the committee is saying. The concepts SG will not take
>> static if work on their plate, because they don't
>> think it's a viable design. They can't, however, stop other people from
>> forming a static if SG if critical mass for such
>> an SG appears. Thus far it hasn't appeared.
>>
>>
>
> Really, a SG just for a "function block static if" proposal?
>
> I think the controversial parts of the N3329 proposal are mostly about
> conflicts with concepts.
>
The "controversial" parts of N3329 are that:
1) it does not introduce a new scope, and
2) the non-selected branch is completely ignored (the tokens aren't even
required to be parseable)
This makes it fundamentally incompatible with the template model used by at
least two major implementations.
If, instead, it introduced a new scope (as proposed in this thread) and we
had a requirement that it is possible to instantiate each arm of the static
if (that is, the same requirement we have for other token sequences in
templates), then I believe the over-my-dead-body objections from
implementors would disappear.
--
---
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/.
--001a11c2332cc6307704e3880e5e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 11:27 AM, Alex B <span dir=3D"ltr"><<a href=3D"ma=
ilto:devalexb@gmail.com" target=3D"_blank">devalexb@gmail.com</a>></span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div class=3D"im">On Fri, Aug 9, 2013 at 3:57 AM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">
<div>On 9 August 2013 10:43, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><br><div>That's the part I don't =
understand. Why is this an either/or question <i>at all</i>? As I understan=
d it, the people pushing for static if are not the same people pushing for =
concepts lite. So... why not let them develop a static if technical specifi=
cation? Why should the standards committee basically so "Go away until=
these other guys finish"?<br>
</div></div></blockquote><div><br></div></div><div>That's not what the =
committee is saying. The concepts SG will not take static if work on their =
plate, because they don't<br>think it's a viable design. They can&#=
39;t, however, stop other people from forming a static if SG if critical ma=
ss for such<br>
an SG appears. Thus far it hasn't appeared. <br>=A0<br></div></div></di=
v></div></blockquote><div><br></div></div><div>Really, a SG just for a &quo=
t;function block static if" proposal?</div>
<div><br></div><div>I think the controversial parts of the N3329 proposal a=
re mostly about conflicts with concepts.</div></div></div></div></blockquot=
e><div><br></div><div>The "controversial" parts of N3329 are that=
:</div>
<div>1) it does not introduce a new scope, and</div><div>2) the non-selecte=
d branch is completely ignored (the tokens aren't even required to be p=
arseable)</div><div><br></div><div>This makes it fundamentally incompatible=
with the template model used by at least two major implementations.</div>
<div><br></div><div>If, instead, it introduced a new scope (as proposed in =
this thread) and we had a requirement that it is possible to instantiate ea=
ch arm of the static if (that is, the same requirement we have for other to=
ken sequences in templates), then I believe the over-my-dead-body objection=
s from implementors would disappear.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2332cc6307704e3880e5e--
.
Author: Alex B <devalexb@gmail.com>
Date: Fri, 9 Aug 2013 14:51:13 -0400
Raw View
--001a11336460460d7504e38842b4
Content-Type: text/plain; charset=ISO-8859-1
>
> 2) the non-selected branch is completely ignored (the tokens aren't even
> required to be parseable)
>
By "not required to be parseable", do you refer to this (section 2.1 of the
proposal):
*"If the constant expression evaluates to zero, the guarded code is
tokenized and ensured to be brace-balanced, but otherwise not analyzed."*
--
---
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/.
--001a11336460460d7504e38842b4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"gmail_quote">2) the non-selected branch is completely ignored=
(the tokens aren't even required to be parseable)<br></div></blockquot=
e><div><br></div><div>By "not required to be parseable", do you r=
efer to this (section 2.1 of the proposal):</div>
<div><i>"If the constant expression evaluates to zero, the guarded cod=
e is tokenized and ensured to be brace-balanced, but otherwise <u><b>not an=
alyzed</b></u>."</i></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11336460460d7504e38842b4--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 9 Aug 2013 22:03:48 +0300
Raw View
--047d7bd766de428f2504e3886f20
Content-Type: text/plain; charset=ISO-8859-1
On 9 August 2013 21:36, Richard Smith <richard@metafoo.co.uk> wrote:
> The "controversial" parts of N3329 are that:
> 1) it does not introduce a new scope, and
> 2) the non-selected branch is completely ignored (the tokens aren't even
> required to be parseable)
>
> This makes it fundamentally incompatible with the template model used by
> at least two major implementations.
>
> If, instead, it introduced a new scope (as proposed in this thread) and we
> had a requirement that it is possible to instantiate each arm of the static
> if (that is, the same requirement we have for other token sequences in
> templates), then I believe the over-my-dead-body objections from
> implementors would disappear.
>
>
>
>
I may misunderstand what the instantiation of both branches really means,
but it gives me the impression
that it makes static if completely useless. The whole point of having a
static if is being able to write
code where the branch not taken can be ill-formed.
--
---
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/.
--047d7bd766de428f2504e3886f20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 August 2013 21:36, Richard Smith <span dir=3D"ltr"><<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
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">The "controversial" parts of N3329=
are that:<div class=3D"gmail_quote">
<div>1) it does not introduce a new scope, and</div><div>2) the non-selecte=
d branch is completely ignored (the tokens aren't even required to be p=
arseable)</div><div><br></div><div>This makes it fundamentally incompatible=
with the template model used by at least two major implementations.</div>
<div><br></div><div>If, instead, it introduced a new scope (as proposed in =
this thread) and we had a requirement that it is possible to instantiate ea=
ch arm of the static if (that is, the same requirement we have for other to=
ken sequences in templates), then I believe the over-my-dead-body objection=
s from implementors would disappear.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I may misunderstand wh=
at the instantiation of both branches really means, but it gives me the imp=
ression<br>that it makes static if completely useless. The whole point of h=
aving a static if is being able to write<br>
code where the branch not taken can be ill-formed. <br></div></div><br></di=
v></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bd766de428f2504e3886f20--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 9 Aug 2013 13:44:22 -0700
Raw View
--047d7b2e4e1aee4c4804e389d613
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 9, 2013 at 12:03 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 9 August 2013 21:36, Richard Smith <richard@metafoo.co.uk> wrote:
>
>> The "controversial" parts of N3329 are that:
>> 1) it does not introduce a new scope, and
>> 2) the non-selected branch is completely ignored (the tokens aren't even
>> required to be parseable)
>>
>> This makes it fundamentally incompatible with the template model used by
>> at least two major implementations.
>>
>> If, instead, it introduced a new scope (as proposed in this thread) and
>> we had a requirement that it is possible to instantiate each arm of the
>> static if (that is, the same requirement we have for other token sequences
>> in templates), then I believe the over-my-dead-body objections from
>> implementors would disappear.
>>
>>
>>
>>
> I may misunderstand what the instantiation of both branches really means,
> but it gives me the impression
> that it makes static if completely useless. The whole point of having a
> static if is being able to write
> code where the branch not taken can be ill-formed.
>
Sorry, my explanation wasn't very clear. I mean, we would need a
requirement that there exists some set of template arguments for which it
is possible to instantiate each arm of the static if *in isolation*. Put
another way, if we treated each arm of the static if as a separate function
template, that function template must not be ill-formed.
The relevant rule for templates is N3690 [temp.res]p8: "If no valid
specialization can be generated for a template, and that template is not
instantiated, the template is ill-formed, no diagnostic required." This is
what allows implementations to parse templates and build an AST from them
before they are instantiated. We couldn't do that if we had to treat the
body of a static if as token soup.
--
---
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/.
--047d7b2e4e1aee4c4804e389d613
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 12:03 PM, Ville Voutilainen <span dir=3D"ltr"><<a=
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div dir=3D"ltr">On 9 August 2013 21:36, Richard Smith <span dir=3D"ltr">&l=
t;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafo=
o.co.uk</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The "controversial" parts of N3329=
are that:<div class=3D"gmail_quote">
<div>1) it does not introduce a new scope, and</div><div>2) the non-selecte=
d branch is completely ignored (the tokens aren't even required to be p=
arseable)</div><div><br></div><div>This makes it fundamentally incompatible=
with the template model used by at least two major implementations.</div>
<div><br></div><div>If, instead, it introduced a new scope (as proposed in =
this thread) and we had a requirement that it is possible to instantiate ea=
ch arm of the static if (that is, the same requirement we have for other to=
ken sequences in templates), then I believe the over-my-dead-body objection=
s from implementors would disappear.</div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div></div><div>I may misunderst=
and what the instantiation of both branches really means, but it gives me t=
he impression<br>that it makes static if completely useless. The whole poin=
t of having a static if is being able to write<br>
code where the branch not taken can be ill-formed.=A0</div></div></div></di=
v></blockquote><div><br></div><div>Sorry, my explanation wasn't very cl=
ear. I mean, we would need a requirement that there exists some set of temp=
late arguments for which it is possible to instantiate each arm of the stat=
ic if *in isolation*. Put another way, if we treated each arm of the static=
if as a separate function template, that function template must not be ill=
-formed.</div>
<div><br></div><div>The relevant rule for templates is N3690 [temp.res]p8: =
"If no valid specialization can be generated for a template, and that =
template is not instantiated, the template is ill-formed, no diagnostic req=
uired." This is what allows implementations to parse templates and bui=
ld an AST from them before they are instantiated. We couldn't do that i=
f we had to treat the body of a static if as token soup.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b2e4e1aee4c4804e389d613--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 10 Aug 2013 00:02:12 +0300
Raw View
--001a11c22780b05cbd04e38a16b8
Content-Type: text/plain; charset=ISO-8859-1
On 9 August 2013 23:44, Richard Smith <richard@metafoo.co.uk> wrote:
>
> Sorry, my explanation wasn't very clear. I mean, we would need a
> requirement that there exists some set of template arguments for which it
> is possible to instantiate each arm of the static if *in isolation*. Put
> another way, if we treated each arm of the static if as a separate function
> template, that function template must not be ill-formed.
>
> The relevant rule for templates is N3690 [temp.res]p8: "If no valid
> specialization can be generated for a template, and that template is not
> instantiated, the template is ill-formed, no diagnostic required." This is
> what allows implementations to parse templates and build an AST from them
> before they are instantiated. We couldn't do that if we had to treat the
> body of a static if as token soup.
>
>
>
>
Thank you very much, that's an extremely illuminating explanation! It also
explains the brief remarks
about "damage to AST-based implementations" by a certain Texan professor. ;)
Is it so that building the AST requires non-dependent lookups to happen, by
which it then becomes
extremely significant whether a new scope is created or not? I'm not quite
up to speed on why
the scope question was so important, I didn't grasp the reasoning provided
in the meeting it
was discussed.
--
---
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/.
--001a11c22780b05cbd04e38a16b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 August 2013 23:44, Richard Smith <span dir=3D"ltr"><<a href=
=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</=
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"><br><div class=3D"gmail_quote"><div>Sorry, m=
y explanation wasn't very clear. I mean, we would need a requirement th=
at there exists some set of template arguments for which it is possible to =
instantiate each arm of the static if *in isolation*. Put another way, if w=
e treated each arm of the static if as a separate function template, that f=
unction template must not be ill-formed.</div>
<div><br></div><div>The relevant rule for templates is N3690 [temp.res]p8: =
"If no valid specialization can be generated for a template, and that =
template is not instantiated, the template is ill-formed, no diagnostic req=
uired." This is what allows implementations to parse templates and bui=
ld an AST from them before they are instantiated. We couldn't do that i=
f we had to treat the body of a static if as token soup.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Thank you very much, t=
hat's an extremely illuminating explanation! It also explains the brief=
remarks<br></div><div>about "damage to AST-based implementations"=
; by a certain Texan professor. ;)<br>
<br></div><div>Is it so that building the AST requires non-dependent lookup=
s to happen, by which it then becomes<br>extremely significant whether a ne=
w scope is created or not? I'm not quite up to speed on why<br></div>
<div>the scope question was so important, I didn't grasp the reasoning =
provided in the meeting it<br>was discussed.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c22780b05cbd04e38a16b8--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 9 Aug 2013 15:25:55 -0700
Raw View
--089e013a1c5a1b8de704e38b4275
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 9, 2013 at 2:02 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 9 August 2013 23:44, Richard Smith <richard@metafoo.co.uk> wrote:
>
>> Sorry, my explanation wasn't very clear. I mean, we would need a
>> requirement that there exists some set of template arguments for which it
>> is possible to instantiate each arm of the static if *in isolation*. Put
>> another way, if we treated each arm of the static if as a separate function
>> template, that function template must not be ill-formed.
>>
>> The relevant rule for templates is N3690 [temp.res]p8: "If no valid
>> specialization can be generated for a template, and that template is not
>> instantiated, the template is ill-formed, no diagnostic required." This is
>> what allows implementations to parse templates and build an AST from them
>> before they are instantiated. We couldn't do that if we had to treat the
>> body of a static if as token soup.
>>
>
> Thank you very much, that's an extremely illuminating explanation! It also
> explains the brief remarks
> about "damage to AST-based implementations" by a certain Texan professor.
> ;)
>
> Is it so that building the AST requires non-dependent lookups to happen,
> by which it then becomes
> extremely significant whether a new scope is created or not? I'm not quite
> up to speed on why
> the scope question was so important, I didn't grasp the reasoning provided
> in the meeting it
> was discussed.
>
The scope question is important for the same reason -- it significantly
harms implementations that parse template definitions. Consider:
int n;
template<typename T> int f() {
static if (T::condition)
typedef int X;
else
extern void X(int);
X(n); // #1
return n; // #2
}
What is line #1? Is it a declaration of a variable 'n' (if the condition is
true), or is it a call to the function 'X' (if the condition is false)?
What is 'n' in line #2? Is it the local variable declared on the previous
line, or the global variable?
It would require some serious implementation heroics to handle these cases
under the early-parsed templates model.
More abstractly, here's another excerpt from [temp.res]p8: "Knowing which
names are type names allows the syntax of every template to be checked." As
seen above, that valuable property doesn't hold any more if 'static if'
doesn't introduce a scope.
--
---
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/.
--089e013a1c5a1b8de704e38b4275
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 2:02 PM, Ville Voutilainen <span dir=3D"ltr"><<a =
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutila=
inen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr">On 9 August 2013 23:44, Richard Smith <span dir=3D"ltr">&l=
t;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafo=
o.co.uk</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Sorry, my explanation wasn't very clear.=
I mean, we would need a requirement that there exists some set of template=
arguments for which it is possible to instantiate each arm of the static i=
f *in isolation*. Put another way, if we treated each arm of the static if =
as a separate function template, that function template must not be ill-for=
med.<br>
<div class=3D"gmail_quote">
<div><br></div><div>The relevant rule for templates is N3690 [temp.res]p8: =
"If no valid specialization can be generated for a template, and that =
template is not instantiated, the template is ill-formed, no diagnostic req=
uired." This is what allows implementations to parse templates and bui=
ld an AST from them before they are instantiated. We couldn't do that i=
f we had to treat the body of a static if as token soup.</div>
</div></blockquote><div><br></div></div><div>Thank you very much, that'=
s an extremely illuminating explanation! It also explains the brief remarks=
<br></div><div>about "damage to AST-based implementations" by a c=
ertain Texan professor. ;)<br>
<br></div><div>Is it so that building the AST requires non-dependent lookup=
s to happen, by which it then becomes<br>extremely significant whether a ne=
w scope is created or not? I'm not quite up to speed on why<br></div>
<div>the scope question was so important, I didn't grasp the reasoning =
provided in the meeting it<br>was discussed.</div></div></div></div></block=
quote><div><br></div><div>The scope question is important for the same reas=
on -- it significantly harms implementations that parse template definition=
s. Consider:</div>
<div><br></div><div>int n;</div><div>template<typename T> int f() {</=
div><div>=A0 static if (T::condition)</div><div>=A0 =A0 typedef int X;</div=
><div>=A0 else</div><div>=A0 =A0 extern void X(int);</div><div>=A0 X(n); //=
#1</div><div>
=A0 return n; // #2</div><div>}</div><div><br></div><div>What is line #1? I=
s it a declaration of a variable 'n' (if the condition is true), or=
is it a call to the function 'X' (if the condition is false)?</div=
>
<div>What is 'n' in line #2? Is it the local variable declared on t=
he previous line, or the global variable?</div><div><br></div><div>It would=
require some serious implementation heroics to handle these cases under th=
e early-parsed templates model.</div>
<div><br></div><div>More abstractly, here's another excerpt from [temp.=
res]p8: "Knowing which names are type names allows the syntax of every=
template to be checked." As seen above, that valuable property doesn&=
#39;t hold any more if 'static if' doesn't introduce a scope.</=
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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e013a1c5a1b8de704e38b4275--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 10 Aug 2013 02:13:59 +0300
Raw View
--089e013cbae8fe6f9904e38bedba
Content-Type: text/plain; charset=ISO-8859-1
On 10 August 2013 01:25, Richard Smith <richard@metafoo.co.uk> wrote:
>
> The scope question is important for the same reason -- it significantly
> harms implementations that parse template definitions. Consider:
>
> int n;
> template<typename T> int f() {
> static if (T::condition)
> typedef int X;
> else
> extern void X(int);
> X(n); // #1
> return n; // #2
> }
>
> What is line #1? Is it a declaration of a variable 'n' (if the condition
> is true), or is it a call to the function 'X' (if the condition is false)?
> What is 'n' in line #2? Is it the local variable declared on the previous
> line, or the global variable?
>
> It would require some serious implementation heroics to handle these cases
> under the early-parsed templates model.
>
> More abstractly, here's another excerpt from [temp.res]p8: "Knowing which
> names are type names allows the syntax of every template to be checked." As
> seen above, that valuable property doesn't hold any more if 'static if'
> doesn't introduce a scope.
>
>
>
>
So with your example, #1 is ill-formed, as it won't find anything with its
lookup, and #2 returns the global n.
And, to put it simply, I can do things like
void whatever()
{
/* common block */
static if (cond) {
// use things in common block
} else {
// use things in common block
}
}
but not
void whatever()
{
static if (cond) {
// whatever
} else {
// whatever different
}
/* common block */
// nothing in the static if-else is found by lookup here, since it's a
new nested scope
}
and modifying your example,
int n;
extern void X(int);
template<typename T> int f() {
static if (T::condition)
typedef int X;
X(n); // #1
return n; // #2
}
the static if is a new scope, so #1 is a call of the extern function and #2
returns the global,
regardless of what the static if desperately tried to do to shadow the
global X.
--
---
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/.
--089e013cbae8fe6f9904e38bedba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 August 2013 01:25, Richard Smith <span dir=3D"ltr"><<a hre=
f=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class=3D"gmail_q=
uote"><div>The scope question is important for the same reason -- it signif=
icantly harms implementations that parse template definitions. Consider:</d=
iv>
<div><br></div><div>int n;</div><div>template<typename T> int f() {</=
div><div>=A0 static if (T::condition)</div><div>=A0 =A0 typedef int X;</div=
><div>=A0 else</div><div>=A0 =A0 extern void X(int);</div><div>=A0 X(n); //=
#1</div>
<div>
=A0 return n; // #2</div><div>}</div><div><br></div><div>What is line #1? I=
s it a declaration of a variable 'n' (if the condition is true), or=
is it a call to the function 'X' (if the condition is false)?</div=
>
<div>What is 'n' in line #2? Is it the local variable declared on t=
he previous line, or the global variable?</div><div><br></div><div>It would=
require some serious implementation heroics to handle these cases under th=
e early-parsed templates model.</div>
<div><br></div><div>More abstractly, here's another excerpt from [temp.=
res]p8: "Knowing which names are type names allows the syntax of every=
template to be checked." As seen above, that valuable property doesn&=
#39;t hold any more if 'static if' doesn't introduce a scope.</=
div>
</div><div class=3D""><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>So with your example, =
#1 is ill-formed, as it won't find anything with its lookup,=A0 and #2 =
returns the global n.<br></div><div>And, to put it simply, I can do things =
like<br>
<br></div><div>void whatever()<br>{<br></div><div>=A0=A0=A0 /* common block=
*/<br></div><div>=A0=A0=A0 static if (cond) {<br></div><div>=A0=A0=A0 // u=
se things in common block<br></div><div>=A0=A0=A0 } else {<br><div>=A0=A0=
=A0 // use things in common block<br>
</div>=A0=A0=A0 }<br></div><div>}<br></div></div><br></div><div class=3D"gm=
ail_extra">but not<br><br><div>void whatever()<br>{<br></div><div></div><di=
v>=A0=A0=A0 static if (cond) {<br></div><div>=A0=A0=A0 // whatever<br></div=
><div>=A0=A0=A0 } else {<br>
<div>=A0=A0=A0 // whatever different<br></div>=A0=A0=A0 }<br></div><div>=A0=
=A0=A0 /* common block */<br></div><div>=A0=A0 // nothing in the static if-=
else is found by lookup here, since it's a new nested scope<br></div><d=
iv>}<br></div><br>
</div><div class=3D"gmail_extra">and modifying your example,<br><br><div>in=
t n;</div><div><div>extern void X(int);</div><br>template<typename T>=
int f() {</div><div>=A0 static if (T::condition)</div><div>=A0 =A0 typedef=
int X;</div>
=A0 X(n); // #1<div>
=A0 return n; // #2</div><div>}</div><div><br></div>the static if is a new =
scope, so #1 is a call of the extern function and #2 returns the global,<br=
>regardless of what the static if desperately tried to do to shadow the glo=
bal X.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e013cbae8fe6f9904e38bedba--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 9 Aug 2013 16:20:18 -0700
Raw View
--001a11c2487a902d0b04e38c04ec
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 9, 2013 at 4:13 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 10 August 2013 01:25, Richard Smith <richard@metafoo.co.uk> wrote:
>
>>
>> The scope question is important for the same reason -- it significantly
>> harms implementations that parse template definitions. Consider:
>>
>> int n;
>> template<typename T> int f() {
>> static if (T::condition)
>> typedef int X;
>> else
>> extern void X(int);
>> X(n); // #1
>> return n; // #2
>> }
>>
>> What is line #1? Is it a declaration of a variable 'n' (if the condition
>> is true), or is it a call to the function 'X' (if the condition is false)?
>> What is 'n' in line #2? Is it the local variable declared on the previous
>> line, or the global variable?
>>
>> It would require some serious implementation heroics to handle these
>> cases under the early-parsed templates model.
>>
>> More abstractly, here's another excerpt from [temp.res]p8: "Knowing which
>> names are type names allows the syntax of every template to be checked." As
>> seen above, that valuable property doesn't hold any more if 'static if'
>> doesn't introduce a scope.
>>
>>
>>
>>
> So with your example, #1 is ill-formed, as it won't find anything with its
> lookup, and #2 returns the global n.
> And, to put it simply, I can do things like
>
> void whatever()
> {
> /* common block */
> static if (cond) {
> // use things in common block
> } else {
> // use things in common block
> }
> }
>
> but not
>
> void whatever()
> {
> static if (cond) {
> // whatever
> } else {
> // whatever different
> }
> /* common block */
> // nothing in the static if-else is found by lookup here, since it's a
> new nested scope
> }
>
> and modifying your example,
>
> int n;
> extern void X(int);
>
> template<typename T> int f() {
> static if (T::condition)
> typedef int X;
> X(n); // #1
> return n; // #2
> }
>
> the static if is a new scope, so #1 is a call of the extern function and
> #2 returns the global,
> regardless of what the static if desperately tried to do to shadow the
> global X.
>
Yes, exactly.
--
---
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/.
--001a11c2487a902d0b04e38c04ec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 4:13 PM, Ville Voutilainen <span dir=3D"ltr"><<a =
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutila=
inen@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 10 August 2013 01:25, Richard Smith <span dir=
=3D"ltr"><<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ric=
hard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class=3D"gmail_q=
uote"><div>The scope question is important for the same reason -- it signif=
icantly harms implementations that parse template definitions. Consider:</d=
iv>
<div><br></div><div>int n;</div><div>template<typename T> int f() {</=
div><div>=A0 static if (T::condition)</div><div>=A0 =A0 typedef int X;</div=
><div>=A0 else</div><div>=A0 =A0 extern void X(int);</div><div>=A0 X(n); //=
#1</div>
<div>
=A0 return n; // #2</div><div>}</div><div><br></div><div>What is line #1? I=
s it a declaration of a variable 'n' (if the condition is true), or=
is it a call to the function 'X' (if the condition is false)?</div=
>
<div>What is 'n' in line #2? Is it the local variable declared on t=
he previous line, or the global variable?</div><div><br></div><div>It would=
require some serious implementation heroics to handle these cases under th=
e early-parsed templates model.</div>
<div><br></div><div>More abstractly, here's another excerpt from [temp.=
res]p8: "Knowing which names are type names allows the syntax of every=
template to be checked." As seen above, that valuable property doesn&=
#39;t hold any more if 'static if' doesn't introduce a scope.</=
div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div></div><div>So with your exa=
mple, #1 is ill-formed, as it won't find anything with its lookup,=A0 a=
nd #2 returns the global n.<br></div><div>And, to put it simply, I can do t=
hings like<br>
<br></div><div>void whatever()<br>{<br></div><div>=A0=A0=A0 /* common block=
*/<br></div><div>=A0=A0=A0 static if (cond) {<br></div><div>=A0=A0=A0 // u=
se things in common block<br></div><div>=A0=A0=A0 } else {<br><div>=A0=A0=
=A0 // use things in common block<br>
</div>=A0=A0=A0 }<br></div><div>}<br></div></div><br></div><div class=3D"gm=
ail_extra">but not<br><br><div>void whatever()<br>{<br></div><div></div><di=
v>=A0=A0=A0 static if (cond) {<br></div><div>=A0=A0=A0 // whatever<br></div=
><div>=A0=A0=A0 } else {<br>
<div>=A0=A0=A0 // whatever different<br></div>=A0=A0=A0 }<br></div><div>=A0=
=A0=A0 /* common block */<br></div><div>=A0=A0 // nothing in the static if-=
else is found by lookup here, since it's a new nested scope<br></div><d=
iv>}<br></div><br>
</div><div class=3D"gmail_extra">and modifying your example,<br><br><div>in=
t n;</div><div><div>extern void X(int);</div><div class=3D"im"><br>template=
<typename T> int f() {</div></div><div class=3D"im"><div>=A0 static i=
f (T::condition)</div>
<div>=A0 =A0 typedef int X;</div></div><div class=3D"im">
=A0 X(n); // #1<div>
=A0 return n; // #2</div><div>}</div><div><br></div></div>the static if is =
a new scope, so #1 is a call of the extern function and #2 returns the glob=
al,<br>regardless of what the static if desperately tried to do to shadow t=
he global X.</div>
</div></blockquote><div><br></div><div>Yes, exactly.=A0</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2487a902d0b04e38c04ec--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 9 Aug 2013 18:50:26 -0700 (PDT)
Raw View
------=_Part_887_19597.1376099426970
Content-Type: text/plain; charset=ISO-8859-1
On Friday, August 9, 2013 3:35:34 PM UTC+8, Nicol Bolas wrote:
> I think you're trying to read far too much into a simple example. But if
> you want more details, there was more than one such function in the
> original file. As I said, it was part of a template class that the user
> provides a class that is expected to implement certain interfaces. Some of
> those interfaces are optional, so every optional interface needed a
> forwarding function like that. Which meant each one needed a means to
> detect if the function in question was available.
>
A alternative design choice could have been to ask the user to specify
which interfaces are being supplied. Maybe that would have been more
reasonable than planning on implementing introspection over an open-ended
set of conditions.
> So I needed a general solution that could be applied to many such
> functions. It also needed to be C++98/03 compatible, because not everyone
> has the latest compilers (the original code used a home-grown equivalent to
> std::enable_if).
>
That helps explain why follows some legacy practices, but it remains a poor
point of comparison to code based on a future standard. We should be
comparing C++11 to C++14.
> And that's really the big issue with this sort of metaprogramming. SFINAE
> is not a "basic concept" of C++. It's not something you can look up in the
> standard. It's a *hack*. It cannot be learned from first principles or
> just from a cursory examination of the language. It must be taught
> idiomatically.
>
Yes it's there, in C++11 14.8.2/8. In C++03 it was certainly
underspecified, but it has been made quite concrete. What does "cursory
examination" have to do with anything? Because it isn't based on anything,
it *is* a principle which remains the basis for concepts.
> That's what static if and concepts lite both have in common: they make *
> explicit* what SFINAE was doing implicitly. They turn an idiom into a
> language feature.
>
static_if covers what enable_if does, but that's only one case of SFINAE.
Your given example trait would still need to be implemented in
old-fashioned SFINAE, either using functions or partial specialization.
> Even moreso if the library idiom in question is "not pretty". That is a
> large part of the reason why people don't use metaprogramming. Code needs
> to be legible in order to be maintainable, and metaprogramming is only
> legible to people who are already steeped in its lore. It's like another
> language with its own bizarre and very verbose idioms and lots of "noise"
> that must be "filtered out" before you can understand what's going on.
>
The maintenance tasks which need to be fulfilled result from the surprising
variety of things that go wrong with templates, because C++ has so many
different kinds of constraints on types and expressions. Syntax to help the
user say what they want applies only if they can figure out the error
message in the first place. That is why concepts are quite reasonable to
prioritize.
Why would a relatively inexperienced user of C++ bother learning something
> like that? It's just too much complexity, with a lot of noise and little
> substance to it. Improve the signal-to-noise ratio of metaprogramming, and
> you're *far* more likely to get people to start using it. Give it a real
> basis in the language rather than a hack, and again, you're more likely to
> get people using it. Remove its idiomatic nature, so rather than a
> half-dozen ways of using it, there's one obvious and correct way to
> implement it, and you will again improve the uptake of people using it.
>
I don't *want* to increase the uptake until the newbies would have a higher
chance of success, and fewer arcane semantic dead-ends to contend with.
> Concepts should make it prettier in any case, but static_if doesn't help
>> because it doesn't address the core problem of encapsulating a syntax
>> error. Even with static_if you would have to define the trait, which is 99%
>> of the ugly.
>>
>
> No; 99% of the ugly is that the enable_if syntax confuses the function
> signature to the point that you can barely tell it's even declaring a
> function.
>
Maybe you find that enormous macro beautiful, but I think you're just
counting lines wrong.
--
---
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_887_19597.1376099426970
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, August 9, 2013 3:35:34 PM UTC+8, Nicol =
Bolas wrote:<div> </div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">I think you're trying to read far too much into a simple ex=
ample. But if you want more details, there was more than one such function =
in the original file. As I said, it was part of a template class that the u=
ser provides a class that is expected to implement certain interfaces. Some=
of those interfaces are optional, so every optional interface needed a for=
warding function like that. Which meant each one needed a means to detect i=
f the function in question was available.<br></div></blockquote><div><br>A =
alternative design choice could have been to ask the user to specify which =
interfaces are being supplied. Maybe that would have been more reasonable t=
han planning on implementing introspection over an open-ended set of condit=
ions.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>So I needed a general solution that could be applied to many =
such functions. It also needed to be C++98/03 compatible, because not every=
one has the latest compilers (the original code used a home-grown equivalen=
t to std::enable_if).<br></div></div></blockquote><div><br>That helps expla=
in why follows some legacy practices, but it remains a poor point of compar=
ison to code based on a future standard. We should be comparing C++11 to C+=
+14.<br></div><div> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">And that's really the big issue with this sort of metapro=
gramming. SFINAE is not a "basic concept" of C++. It's not something you ca=
n look up in the standard. It's a <i>hack</i>. It cannot be learned from fi=
rst principles or just from a cursory examination of the language. It must =
be taught idiomatically.<br></div></blockquote><div><br>Yes it's there, in=
C++11 14.8.2/8. In C++03 it was certainly underspecified, but it has been =
made quite concrete. What does "cursory examination" have to do with anythi=
ng? Because it isn't based on anything, it <i>is</i> a principle which rema=
ins the basis for concepts.<br></div><div> </div><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"><div>That's what static if and con=
cepts lite both have in common: they make <i>explicit</i> what SFINAE was d=
oing implicitly. They turn an idiom into a language feature.<br></div></div=
></blockquote><div><br>static_if covers what enable_if does, but that's onl=
y one case of SFINAE. Your given example trait would still need to be imple=
mented in old-fashioned SFINAE, either using functions or partial specializ=
ation.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Even moreso if the library idiom in question is "not pretty".=
That is a large part of the reason why people don't use metaprogramming. C=
ode needs to be legible in order to be maintainable, and metaprogramming is=
only legible to people who are already steeped in its lore. It's like anot=
her language with its own bizarre and very verbose idioms and lots of "nois=
e" that must be "filtered out" before you can understand what's going on.<b=
r></div></div></blockquote><div><br>The maintenance tasks which need to be =
fulfilled result from the surprising variety of things that go wrong with t=
emplates, because C++ has so many different kinds of constraints on types a=
nd expressions. Syntax to help the user say what they want applies only if =
they can figure out the error message in the first place. That is why conce=
pts are quite reasonable to prioritize.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>Why would a relatively inexper=
ienced user of C++ bother learning something like that? It's just too much =
complexity, with a lot of noise and little substance to it. Improve the sig=
nal-to-noise ratio of metaprogramming, and you're <i>far</i> more likely to=
get people to start using it. Give it a real basis in the language rather =
than a hack, and again, you're more likely to get people using it. Remove i=
ts idiomatic nature, so rather than a half-dozen ways of using it, there's =
one obvious and correct way to implement it, and you will again improve the=
uptake of people using it.<br></div></div></blockquote><div><br>I don't <i=
>want</i> to increase the uptake until the newbies would have a higher chan=
ce of success, and fewer arcane semantic dead-ends to contend with.<br>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Concepts should ma=
ke it prettier in any case, but static_if doesn't help because it doesn't a=
ddress the core problem of encapsulating a syntax error. Even with static_i=
f you would have to define the trait, which is 99% of the ugly.</div></div>=
</blockquote><div><br>No; 99% of the ugly is that the enable_if syntax conf=
uses the function signature to the point that you can barely tell it's even=
declaring a function.</div></div></blockquote><div> <br>Maybe you fin=
d that enormous macro beautiful, but I think you're just counting lines wro=
ng.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_887_19597.1376099426970--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 9 Aug 2013 19:07:55 -0700 (PDT)
Raw View
------=_Part_880_26934419.1376100475807
Content-Type: text/plain; charset=ISO-8859-1
On Friday, August 9, 2013 3:25:55 PM UTC-7, Richard Smith wrote:
>
> On Fri, Aug 9, 2013 at 2:02 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 9 August 2013 23:44, Richard Smith <ric...@metafoo.co.uk <javascript:>
>> > wrote:
>>
>>> Sorry, my explanation wasn't very clear. I mean, we would need a
>>> requirement that there exists some set of template arguments for which it
>>> is possible to instantiate each arm of the static if *in isolation*. Put
>>> another way, if we treated each arm of the static if as a separate function
>>> template, that function template must not be ill-formed.
>>>
>>> The relevant rule for templates is N3690 [temp.res]p8: "If no valid
>>> specialization can be generated for a template, and that template is not
>>> instantiated, the template is ill-formed, no diagnostic required." This is
>>> what allows implementations to parse templates and build an AST from them
>>> before they are instantiated. We couldn't do that if we had to treat the
>>> body of a static if as token soup.
>>>
>>
>> Thank you very much, that's an extremely illuminating explanation! It
>> also explains the brief remarks
>> about "damage to AST-based implementations" by a certain Texan professor.
>> ;)
>>
>> Is it so that building the AST requires non-dependent lookups to happen,
>> by which it then becomes
>> extremely significant whether a new scope is created or not? I'm not
>> quite up to speed on why
>> the scope question was so important, I didn't grasp the reasoning
>> provided in the meeting it
>> was discussed.
>>
>
> The scope question is important for the same reason -- it significantly
> harms implementations that parse template definitions. Consider:
>
> int n;
> template<typename T> int f() {
> static if (T::condition)
> typedef int X;
> else
> extern void X(int);
> X(n); // #1
> return n; // #2
> }
>
> What is line #1? Is it a declaration of a variable 'n' (if the condition
> is true), or is it a call to the function 'X' (if the condition is false)?
> What is 'n' in line #2? Is it the local variable declared on the previous
> line, or the global variable?
>
> It would require some serious implementation heroics to handle these cases
> under the early-parsed templates model.
>
> More abstractly, here's another excerpt from [temp.res]p8: "Knowing which
> names are type names allows the syntax of every template to be checked." As
> seen above, that valuable property doesn't hold any more if 'static if'
> doesn't introduce a scope.
>
But without the relaxed scoping rules, you lose a lot of the usefulness of
static_if. One of the biggest advantages of static_if's scoping rules over
concepts is code locality. To do any type-based conditional testing with
concepts, you *must* introduce a function. With static_if, if you want to
call a function or use a default variable if that function isn't available,
it's just this simple:
template<typename T> void Func(const T &t)
{
static if(/*can call T::OptFunc*/)
bool test = t.OptFunc();
else
bool test = true;
//Do stuff with test.
}
It's easy to read, understand, and use.
That being said, I understand the basic issue with the proposed scoping
rules. I would say that the way to go about solving it is to leave the
scoping rules themselves alone. Instead, restrict the ability of
static_if's to introduce names that exit the scope. Specifically, if a
static if branch introduces a name that will be visible after the static_if:
1: Every possible condition must *also* introduce that same name.
2: Every possible condition must result in a name that is "functionally
identical" as far as the following code is concerned. If the name
introduced is a variable, that must be a variable of the same type in all
cases (not merely convertible to or a type with a similar interface. The
exact same type). If the name introduced is a typedef, that typedef must
result in the same type in all cases.
I know that last part will be annoying for many uses. But the idea is to
preserve the effectiveness of static_if for things that would be too
tedious for concepts or needlessly break code locality. static_if is a
scalpel; it should not be used for things like picking one type vs. another
based on some property. We have type traits for that, and it's better to
move those kinds of decisions out of a function body.
--
---
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_880_26934419.1376100475807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 9, 2013 3:25:55 PM UTC-7, Richard Smith =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Aug 9, 2013 at 2=
:02 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"s38gJPIiyiEJ">ville.vo...@gmail.com=
</a>></span> wrote:<br><div class=3D"gmail_quote"><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">On 9 August 2013 23:44, Richard Smith <span dir=3D"ltr">&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"s38gJP=
IiyiEJ">ric...@metafoo.co.uk</a>></span> wrote:<br><div><div class=3D"gm=
ail_quote">
<div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Sorry, my explanation wasn't very clear. I m=
ean, we would need a requirement that there exists some set of template arg=
uments for which it is possible to instantiate each arm of the static if *i=
n isolation*. Put another way, if we treated each arm of the static if as a=
separate function template, that function template must not be ill-formed.=
<br>
<div class=3D"gmail_quote">
<div><br></div><div>The relevant rule for templates is N3690 [temp.res]p8: =
"If no valid specialization can be generated for a template, and that templ=
ate is not instantiated, the template is ill-formed, no diagnostic required=
.." This is what allows implementations to parse templates and build an AST =
from them before they are instantiated. We couldn't do that if we had to tr=
eat the body of a static if as token soup.</div>
</div></blockquote><div><br></div></div><div>Thank you very much, that's an=
extremely illuminating explanation! It also explains the brief remarks<br>=
</div><div>about "damage to AST-based implementations" by a certain Texan p=
rofessor. ;)<br>
<br></div><div>Is it so that building the AST requires non-dependent lookup=
s to happen, by which it then becomes<br>extremely significant whether a ne=
w scope is created or not? I'm not quite up to speed on why<br></div>
<div>the scope question was so important, I didn't grasp the reasoning prov=
ided in the meeting it<br>was discussed.</div></div></div></div></blockquot=
e><div><br></div><div>The scope question is important for the same reason -=
- it significantly harms implementations that parse template definitions. C=
onsider:</div>
<div><br></div><div>int n;</div><div>template<typename T> int f() {</=
div><div> static if (T::condition)</div><div> typedef in=
t X;</div><div> else</div><div> extern void X(int);</div=
><div> X(n); // #1</div><div>
return n; // #2</div><div>}</div><div><br></div><div>What is line #1=
? Is it a declaration of a variable 'n' (if the condition is true), or is i=
t a call to the function 'X' (if the condition is false)?</div>
<div>What is 'n' in line #2? Is it the local variable declared on the previ=
ous line, or the global variable?</div><div><br></div><div>It would require=
some serious implementation heroics to handle these cases under the early-=
parsed templates model.</div>
<div><br></div><div>More abstractly, here's another excerpt from [temp.res]=
p8: "Knowing which names are type names allows the syntax of every template=
to be checked." As seen above, that valuable property doesn't hold any mor=
e if 'static if' doesn't introduce a scope.</div></div></blockquote><div><b=
r>But without the relaxed scoping rules, you lose a lot of the usefulness o=
f static_if. One of the biggest advantages of static_if's scoping rules ove=
r concepts is code locality. To do any type-based conditional testing with =
concepts, you <i>must</i> introduce a function. With static_if, if you want=
to call a function or use a default variable if that function isn't availa=
ble, it's just this simple:<br><br><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> T </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"styled-b=
y-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">static</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">/*can call T::OptFunc*/</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">bool</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> test </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">OptFunc</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">else</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">bool</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> test </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">true</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 sty=
le=3D"color: #800;" class=3D"styled-by-prettify">//Do stuff with test.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></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></div></code></di=
v><br>It's easy to read, understand, and use.<br><br>That being said, I und=
erstand the basic issue with the proposed scoping rules. I would say that t=
he way to go about solving it is to leave the scoping rules themselves alon=
e. Instead, restrict the ability of static_if's to introduce names that exi=
t the scope. Specifically, if a static if branch introduces a name that wil=
l be visible after the static_if:<br><br>1: Every possible condition must <=
i>also</i> introduce that same name.<br>2: Every possible condition must re=
sult in a name that is "functionally identical" as far as the following cod=
e is concerned. If the name introduced is a variable, that must be a variab=
le of the same type in all cases (not merely convertible to or a type with =
a similar interface. The exact same type). If the name introduced is a type=
def, that typedef must result in the same type in all cases.<br><br>I know =
that last part will be annoying for many uses. But the idea is to preserve =
the effectiveness of static_if for things that would be too tedious for con=
cepts or needlessly break code locality. static_if is a scalpel; it should =
not be used for things like picking one type vs. another based on some prop=
erty. We have type traits for that, and it's better to move those kinds of =
decisions out of a function body.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_880_26934419.1376100475807--
.
Author: Alex B <devalexb@gmail.com>
Date: Fri, 9 Aug 2013 23:00:32 -0400
Raw View
--001a11c3ca1431306204e38f18ca
Content-Type: text/plain; charset=ISO-8859-1
> That being said, I understand the basic issue with the proposed scoping
> rules. I would say that the way to go about solving it is to leave the
> scoping rules themselves alone. Instead, restrict the ability of
> static_if's to introduce names that exit the scope. Specifically, if a
> static if branch introduces a name that will be visible after the static_if:
>
> 1: Every possible condition must *also* introduce that same name.
> 2: Every possible condition must result in a name that is "functionally
> identical" as far as the following code is concerned. If the name
> introduced is a variable, that must be a variable of the same type in all
> cases (not merely convertible to or a type with a similar interface. The
> exact same type). If the name introduced is a typedef, that typedef must
> result in the same type in all cases.
>
> I know that last part will be annoying for many uses. But the idea is to
> preserve the effectiveness of static_if for things that would be too
> tedious for concepts or needlessly break code locality. static_if is a
> scalpel; it should not be used for things like picking one type vs. another
> based on some property. We have type traits for that, and it's better to
> move those kinds of decisions out of a function body.
>
What if you want to declare a variable in one branch and *you want* it to
be destroyed when going out of branch scope (think about a resource wrapped
in a RAII class)? You will have to make sure that the name is different
from all the names in the other branch? It means that changing a name could
change the behavior... that could become a debugging nightmare.
Maybe you can enlighten me, but I fail to see what are the real advantages
of having a name "leak" out of its scope. The example you made could be the
following, which wouldn't require your special rules:
template<typename T> void Func(const T &t)
{
bool test;
static if(/*can call T::OptFunc*/)
test = t.OptFunc();
else
test = true;
//Do stuff with test.
}
But maybe you can come up with another example that would show the
usefulness of what you are asking for?
If it is to conditionally define a type, I don't think that static if
should be made for that. Apart from all the (really) good reasons Richard
mentioned about the implementability of scoping rules, I also think that it
would be really disturbing from a user perspective to have names leak out
of scope. The goal of static if is to allow a metaprogramming style that is
closer to regular non-meta programming style. So it should be as close as
possible to regular if. Names leaking out of scope sounds really unnatural.
If there are specific needs that remain unaddressed, it doesn't mean that
they have to be addressed by static if. But I'm curious to hear what those
needs are.
--
---
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/.
--001a11c3ca1431306204e38f18ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div>That being said, I understand the basic issue with th=
e proposed scoping rules. I would say that the way to go about solving it i=
s to leave the scoping rules themselves alone. Instead, restrict the abilit=
y of static_if's to introduce names that exit the scope. Specifically, =
if a static if branch introduces a name that will be visible after the stat=
ic_if:<br>
<br>1: Every possible condition must <i>also</i> introduce that same name.<=
br>2: Every possible condition must result in a name that is "function=
ally identical" as far as the following code is concerned. If the name=
introduced is a variable, that must be a variable of the same type in all =
cases (not merely convertible to or a type with a similar interface. The ex=
act same type). If the name introduced is a typedef, that typedef must resu=
lt in the same type in all cases.<br>
<br>I know that last part will be annoying for many uses. But the idea is t=
o preserve the effectiveness of static_if for things that would be too tedi=
ous for concepts or needlessly break code locality. static_if is a scalpel;=
it should not be used for things like picking one type vs. another based o=
n some property. We have type traits for that, and it's better to move =
those kinds of decisions out of a function body.<br>
</div></div></blockquote><div><br></div><div>What if you want to declare a =
variable in one branch and=A0<i>you want</i>=A0it to be destroyed when goin=
g out of branch scope (think about a resource wrapped in a RAII class)? You=
will have to make sure that the name is different from all the names in th=
e other branch? It means that changing a name could change the behavior... =
that could become a debugging nightmare.</div>
<div><br></div><div>Maybe you can enlighten me, but I fail to see what are =
the real advantages of having a name "leak" out of its scope. The=
example you made could be the following, which wouldn't require your s=
pecial rules:</div>
<div><br></div><div><span style=3D"font-family:monospace;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">template</span><span style=3D"font-fami=
ly:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)"><</=
span><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
;color:rgb(0,0,136)">typename</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250)">=A0T</span><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250);color:rgb(102,102,0)">></span><s=
pan style=3D"font-family:monospace;background-color:rgb(250,250,250)">=A0</=
span><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
;color:rgb(0,0,136)">void</span><span style=3D"font-family:monospace;backgr=
ound-color:rgb(250,250,250)">=A0</span><span style=3D"font-family:monospace=
;background-color:rgb(250,250,250);color:rgb(102,0,102)">Func</span><span s=
tyle=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(1=
02,102,0)">(</span><span style=3D"font-family:monospace;background-color:rg=
b(250,250,250);color:rgb(0,0,136)">const</span><span style=3D"font-family:m=
onospace;background-color:rgb(250,250,250)">=A0T=A0</span><span style=3D"fo=
nt-family:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)"=
>&</span><span style=3D"font-family:monospace;background-color:rgb(250,=
250,250)">t</span><span style=3D"font-family:monospace;background-color:rgb=
(250,250,250);color:rgb(102,102,0)">)</span><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-color:rgb(250,250,25=
0);color:rgb(102,102,0)">{</span></div><div><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250)"><font color=3D"#666600">=A0 bool t=
est;<br>
</font>=A0=A0</span><span style=3D"font-family:monospace;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">static</span><span style=3D"font-family=
:monospace;background-color:rgb(250,250,250)">=A0</span><span style=3D"font=
-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">if<=
/span><span style=3D"font-family:monospace;background-color:rgb(250,250,250=
);color:rgb(102,102,0)">(</span><span style=3D"font-family:monospace;backgr=
ound-color:rgb(250,250,250);color:rgb(136,0,0)">/*can call T::OptFunc*/</sp=
an><span style=3D"font-family:monospace;background-color:rgb(250,250,250);c=
olor:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;backgroun=
d-color:rgb(250,250,250)"><br>
=A0 =A0=A0</span><span style=3D"font-family:monospace;background-color:rgb(=
250,250,250)">test=A0</span><span style=3D"font-family:monospace;background=
-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span style=3D"font=
-family:monospace;background-color:rgb(250,250,250)">=A0t</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">.</span><span style=3D"font-family:monospace;background-color:rgb(25=
0,250,250);color:rgb(102,0,102)">OptFunc</span><span style=3D"font-family:m=
onospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">();</span>=
<span style=3D"font-family:monospace;background-color:rgb(250,250,250)"><br=
>
=A0=A0</span><span style=3D"font-family:monospace;background-color:rgb(250,=
250,250);color:rgb(0,0,136)">else</span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250)"><br>=A0 =A0=A0</span><span style=3D"fo=
nt-family:monospace;background-color:rgb(250,250,250)">test=A0</span><span =
style=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(=
102,102,0)">=3D</span><span style=3D"font-family:monospace;background-color=
:rgb(250,250,250)">=A0</span><span style=3D"font-family:monospace;backgroun=
d-color:rgb(250,250,250);color:rgb(0,0,136)">true</span><span style=3D"font=
-family:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">;=
</span><span style=3D"font-family:monospace;background-color:rgb(250,250,25=
0)"><br>
<br>=A0=A0</span><span style=3D"font-family:monospace;background-color:rgb(=
250,250,250);color:rgb(136,0,0)">//Do stuff with test.</span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250)"><br></span><span =
style=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(=
102,102,0)">}</span><br>
</div><div><br></div><div>But maybe you can come up with another example th=
at would show the usefulness of what you are asking for?</div><div><br></di=
v><div>If it is to conditionally define a type, I don't think that stat=
ic if should be made for that. Apart from all the (really) good reasons Ric=
hard mentioned about the implementability of scoping rules, I also think th=
at it would be really disturbing from a user perspective to have names leak=
out of scope. The goal of static if is to allow a metaprogramming style th=
at is closer to regular non-meta programming style. So it should be as clos=
e as possible to regular if. Names leaking out of scope sounds really unnat=
ural. If there are specific needs that remain unaddressed, it doesn't m=
ean that they have to be addressed by static if. But I'm curious to hea=
r what those needs are.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c3ca1431306204e38f18ca--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 9 Aug 2013 20:23:36 -0700 (PDT)
Raw View
------=_Part_824_19780469.1376105016023
Content-Type: text/plain; charset=ISO-8859-1
On Friday, August 9, 2013 8:00:32 PM UTC-7, Alex B wrote:
>
>
> That being said, I understand the basic issue with the proposed scoping
>> rules. I would say that the way to go about solving it is to leave the
>> scoping rules themselves alone. Instead, restrict the ability of
>> static_if's to introduce names that exit the scope. Specifically, if a
>> static if branch introduces a name that will be visible after the static_if:
>>
>> 1: Every possible condition must *also* introduce that same name.
>> 2: Every possible condition must result in a name that is "functionally
>> identical" as far as the following code is concerned. If the name
>> introduced is a variable, that must be a variable of the same type in all
>> cases (not merely convertible to or a type with a similar interface. The
>> exact same type). If the name introduced is a typedef, that typedef must
>> result in the same type in all cases.
>>
>> I know that last part will be annoying for many uses. But the idea is to
>> preserve the effectiveness of static_if for things that would be too
>> tedious for concepts or needlessly break code locality. static_if is a
>> scalpel; it should not be used for things like picking one type vs. another
>> based on some property. We have type traits for that, and it's better to
>> move those kinds of decisions out of a function body.
>>
>
> What if you want to declare a variable in one branch and *you want* it to
> be destroyed when going out of branch scope (think about a resource wrapped
> in a RAII class)?
>
Then you add another set of braces. All names introduced at the scope of
the condition are exported; if you don't want a symbol to leave the scope,
you need to explicitly scope it.
You will have to make sure that the name is different from all the names in
> the other branch? It means that changing a name could change the
> behavior... that could become a debugging nightmare.
>
Compilers will emit errors when you do it wrong. If a name leaves the
condition without a corresponding one in another condition, you get a
compiler error.
Maybe you can enlighten me, but I fail to see what are the real advantages
> of having a name "leak" out of its scope. The example you made could be the
> following, which wouldn't require your special rules:
>
> template<typename T> void Func(const T &t)
> {
> bool test;
> static if(/*can call T::OptFunc*/)
> test = t.OptFunc();
> else
> test = true;
>
> //Do stuff with test.
> }
>
> But maybe you can come up with another example that would show the
> usefulness of what you are asking for?
>
You don't have to default construct `test`; that's the usefulness of it.
Not every type is a boolean after all. Some types are expensive to default
construct, and this avoid that. It's also a lot more natural for the user
to initialize variables in situ than to create a default one and then fill
it in after the fact.
If it is to conditionally define a type, I don't think that static if
> should be made for that.
>
But the rules I suggested expressly forbid that. If one branch has it, then
all branches must too. And it must be the same type.
> Apart from all the (really) good reasons Richard mentioned about the
> implementability of scoping rules, I also think that it would be really
> disturbing from a user perspective to have names leak out of scope. The
> goal of static if is to allow a metaprogramming style that is closer to
> regular non-meta programming style.
>
No, the principle goal of static if is to make metaprogramming *easier* for
the user to use. This involves making it more imperative, but it also
involves improved code locality compared to concepts. It involves making it
easier to understand what's going on.
Remember: in the world of concepts, static_if is a scalpel. It solves a
very specific problem: I have a function that will be 90% the same no
matter the condition. But it's going to have a few lines that are
different, based on some static test. If you're putting more than about 4-5
lines in any static_if conditional, then it's probably something that *
deserves* to be done as a function. Much like making long lambda functions
is bad coding style.
--
---
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_824_19780469.1376105016023
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 9, 2013 8:00:32 PM UTC-7, Alex B wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div>That being said, I understand the basic issue with th=
e proposed scoping rules. I would say that the way to go about solving it i=
s to leave the scoping rules themselves alone. Instead, restrict the abilit=
y of static_if's to introduce names that exit the scope. Specifically, if a=
static if branch introduces a name that will be visible after the static_i=
f:<br>
<br>1: Every possible condition must <i>also</i> introduce that same name.<=
br>2: Every possible condition must result in a name that is "functionally =
identical" as far as the following code is concerned. If the name introduce=
d is a variable, that must be a variable of the same type in all cases (not=
merely convertible to or a type with a similar interface. The exact same t=
ype). If the name introduced is a typedef, that typedef must result in the =
same type in all cases.<br>
<br>I know that last part will be annoying for many uses. But the idea is t=
o preserve the effectiveness of static_if for things that would be too tedi=
ous for concepts or needlessly break code locality. static_if is a scalpel;=
it should not be used for things like picking one type vs. another based o=
n some property. We have type traits for that, and it's better to move thos=
e kinds of decisions out of a function body.<br>
</div></div></blockquote><div><br></div><div>What if you want to declare a =
variable in one branch and <i>you want</i> it to be destroyed whe=
n going out of branch scope (think about a resource wrapped in a RAII class=
)?</div></div></div></div></blockquote><div><br>Then you add another set of=
braces. All names introduced at the scope of the condition are exported; i=
f you don't want a symbol to leave the scope, you need to explicitly scope =
it.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div>You will have to make sure that th=
e name is different from all the names in the other branch? It means that c=
hanging a name could change the behavior... that could become a debugging n=
ightmare.</div></div></div></div></blockquote><div><br>Compilers will emit =
errors when you do it wrong. If a name leaves the condition without a corre=
sponding one in another condition, you get a compiler error.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div>Maybe you can enlighten me, but I fail to see what a=
re the real advantages of having a name "leak" out of its scope. The exampl=
e you made could be the following, which wouldn't require your special rule=
s:</div>
<div><br></div><div><span style=3D"font-family:monospace;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">template</span><span style=3D"font-fami=
ly:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)"><</=
span><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
;color:rgb(0,0,136)">typename</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250)"> T</span><span style=3D"font-family:m=
onospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">></span=
><span style=3D"font-family:monospace;background-color:rgb(250,250,250)">&n=
bsp;</span><span style=3D"font-family:monospace;background-color:rgb(250,25=
0,250);color:rgb(0,0,136)">void</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250)"> </span><span style=3D"font-family:=
monospace;background-color:rgb(250,250,250);color:rgb(102,0,102)">Func</spa=
n><span style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(102,102,0)"><wbr>(</span><span style=3D"font-family:monospace;backg=
round-color:rgb(250,250,250);color:rgb(0,0,136)">const</span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250)"> T </sp=
an><span style=3D"font-family:monospace;background-color:rgb(250,250,250);c=
olor:rgb(102,102,0)">&</span><span style=3D"font-family:monospace;backg=
round-color:rgb(250,250,250)">t</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250);color:rgb(102,102,0)">)</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-color:rgb(250,250,25=
0);color:rgb(102,102,0)">{</span></div><div><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250)"><font color=3D"#666600"> boo=
l test;<br>
</font> </span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250);color:rgb(0,0,136)">static</span><span style=3D"font-=
family:monospace;background-color:rgb(250,250,250)"> </span><span styl=
e=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,=
136)">if</span><span style=3D"font-family:monospace;background-color:rgb(25=
0,250,250);color:rgb(102,102,0)">(</span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250);color:rgb(136,0,0)">/*can call T::OptF=
unc*/</span><span style=3D"font-family:monospace;background-color:rgb(250,2=
50,250);color:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250)">test </span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span s=
tyle=3D"font-family:monospace;background-color:rgb(250,250,250)"> t</s=
pan><span style=3D"font-family:monospace;background-color:rgb(250,250,250);=
color:rgb(102,102,0)">.</span><span style=3D"font-family:monospace;backgrou=
nd-color:rgb(250,250,250);color:rgb(102,0,102)">OptFunc</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">();</span><span style=3D"font-family:monospace;background-color:rgb(=
250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-color:rg=
b(250,250,250);color:rgb(0,0,136)">else</span><span style=3D"font-family:mo=
nospace;background-color:rgb(250,250,250)"><br> </span><s=
pan style=3D"font-family:monospace;background-color:rgb(250,250,250)">test&=
nbsp;</span><span style=3D"font-family:monospace;background-color:rgb(250,2=
50,250);color:rgb(102,102,0)">=3D</span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250)"> </span><span style=3D"font-famil=
y:monospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">true</spa=
n><span style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(102,102,0)">;</span><span style=3D"font-family:monospace;background=
-color:rgb(250,250,250)"><br>
<br> </span><span style=3D"font-family:monospace;background-colo=
r:rgb(250,250,250);color:rgb(136,0,0)">//Do stuff with test.</span><span st=
yle=3D"font-family:monospace;background-color:rgb(250,250,250)"><br></span>=
<span style=3D"font-family:monospace;background-color:rgb(250,250,250);colo=
r:rgb(102,102,0)">}</span><br>
</div><div><br></div><div>But maybe you can come up with another example th=
at would show the usefulness of what you are asking for?</div></div></div><=
/div></blockquote><div><br>You don't have to default construct `test`; that=
's the usefulness of it. Not every type is a boolean after all. Some types =
are expensive to default construct, and this avoid that. It's also a lot mo=
re natural for the user to initialize variables in situ than to create a de=
fault one and then fill it in after the fact.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div>If it is to conditionally define a type, I don't think that static =
if should be made for that.</div></div></div></div></blockquote><div><br>Bu=
t the rules I suggested expressly forbid that. If one branch has it, then a=
ll branches must too. And it must be the same type.<br> </div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote"><div>Apart from all the (really) good reasons Richard mentioned =
about the implementability of scoping rules, I also think that it would be =
really disturbing from a user perspective to have names leak out of scope. =
The goal of static if is to allow a metaprogramming style that is closer to=
regular non-meta programming style.</div></div></div></div></blockquote><d=
iv><br>No, the principle goal of static if is to make metaprogramming <i>ea=
sier</i> for the user to use. This involves making it more imperative, but =
it also involves improved code locality compared to concepts. It involves m=
aking it easier to understand what's going on.<br><br>Remember: in the worl=
d of concepts, static_if is a scalpel. It solves a very specific problem: I=
have a function that will be 90% the same no matter the condition. But it'=
s going to have a few lines that are different, based on some static test. =
If you're putting more than about 4-5 lines in any static_if conditional, t=
hen it's probably something that <i>deserves</i> to be done as a function. =
Much like making long lambda functions is bad coding style.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_824_19780469.1376105016023--
.
Author: Alex B <devalexb@gmail.com>
Date: Sat, 10 Aug 2013 00:46:11 -0400
Raw View
--089e0158c2920e49f704e3909271
Content-Type: text/plain; charset=ISO-8859-1
> What if you want to declare a variable in one branch and *you want* it to
>> be destroyed when going out of branch scope (think about a resource wrapped
>> in a RAII class)?
>>
>
> Then you add another set of braces. All names introduced at the scope of
> the condition are exported; if you don't want a symbol to leave the scope,
> you need to explicitly scope it.
>
Uh... that's exactly the kind of thing that the average user would not
think about.
> Compilers will emit errors when you do it wrong. If a name leaves the
> condition without a corresponding one in another condition, you get a
> compiler error.
>
You will get a compiler error *if you try* to use the name outside of the
two static if branches. If you don't try to use it outside, no compiler
error. But still potential different behavior depending on the names
declared the other branch.
> You don't have to default construct `test`; that's the usefulness of it.
>> Not every type is a boolean after all. Some types are expensive to default
>> construct, and this avoid that. It's also a lot more natural for the user
>> to initialize variables in situ than to create a default one and then fill
>> it in after the fact.
>>
>
To prevent default construction, there is std::optional, although I admit I
don't find it ideal since it cannot guarantee that both branches will
construct the type. What you propose does indeed guarantee that.
But the rules I suggested expressly forbid that. If one branch has it, then
> all branches must too. And it must be the same type.
>
Fine.
What I don't like is the implicit nature of the rules you suggested. I
would personally clearly prefer having to "mark" those names to indicate
that they should leak. Such a marked name would then need to have an
equivalent marked name in the other branch. Consider a __leak keyword for
example (I know, the name of the keyword is bad but it is only to
illustrate possible usage):
template<typename T> void Func(const T &t)
{
static if(/*can call T::OptFunc*/)
__leak bool test = t.OptFunc();
else
__leak bool test = true;
//Do stuff with test.
}
Thinking about it, the problem you are trying to solve is not a problem
concerning metaprogramming alone, but regular programming as well. It
happens quite often that a user wants to chose between 2 (or more) ways to
construct an object depending on a *runtime* condition. So it seems to me
that it doesn't have to be strictly related to static if. You could apply
the same (ideally explicit) rules to regular if as well:
template<typename T> void Func(const T &t)
{
if(/*any condition*/)
__leak bool test = foo();
else
__leak bool test = true;
//Do stuff with test.
}
--
---
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/.
--089e0158c2920e49f704e3909271
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote">
<div>What if you want to declare a variable in one branch and=A0<i>you want=
</i>=A0it to be destroyed when going out of branch scope (think about a res=
ource wrapped in a RAII class)?</div></div></div></div></blockquote></div><=
div>
<br>Then you add another set of braces. All names introduced at the scope o=
f the condition are exported; if you don't want a symbol to leave the s=
cope, you need to explicitly scope it.<br></div></div></blockquote><div>
<br></div><div>Uh... that's exactly the kind of thing that the average =
user would not think about.</div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div class=3D"gmail_quote">
<div></div></div></div></div></blockquote></div><div>Compilers will emit er=
rors when you do it wrong. If a name leaves the condition without a corresp=
onding one in another condition, you get a compiler error.<br></div></div>
</blockquote><div><br></div><div>You will get a compiler error <i>if you tr=
y</i> to use the name outside of the two static if branches. If you don'=
;t try to use it outside, no compiler error. But still potential different =
behavior depending on the names declared the other branch.</div>
<div>=A0=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><span style=3D"color:=
rgb(34,34,34)">You don't have to default construct `test`; that's t=
he usefulness of it. Not every type is a boolean after all. Some types are =
expensive to default construct, and this avoid that. It's also a lot mo=
re natural for the user to initialize variables in situ than to create a de=
fault one and then fill it in after the fact.</span><br>
</div></div></div></div></blockquote></div></div></blockquote><div><br></di=
v><div>To prevent default construction, there is std::optional, although I =
admit I don't find it ideal since it cannot guarantee that both branche=
s will construct the type. What you propose does indeed guarantee that.</di=
v>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>But the rules I sugge=
sted expressly forbid that. If one branch has it, then all branches must to=
o. And it must be the same type.<br>
</div></div></blockquote><div><br></div><div>Fine.</div><div><br></div><div=
>What I don't like is the implicit nature of the rules you suggested. I=
would personally clearly prefer having to "mark" those names to =
indicate that they should leak. Such a marked name would then need to have =
an equivalent marked name in the other branch. Consider a __leak keyword fo=
r example (I know, the name of the keyword is bad but it is only to illustr=
ate possible usage):</div>
<div><span style=3D"font-family:monospace;font-size:10px;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">template</span><span style=3D"font-fami=
ly:monospace;font-size:10px;background-color:rgb(250,250,250);color:rgb(102=
,102,0)"><</span><span style=3D"font-family:monospace;font-size:10px;bac=
kground-color:rgb(250,250,250);color:rgb(0,0,136)">typename</span><span sty=
le=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250=
)">=A0T</span><span style=3D"font-family:monospace;font-size:10px;backgroun=
d-color:rgb(250,250,250);color:rgb(102,102,0)">></span><span style=3D"fo=
nt-family:monospace;font-size:10px;background-color:rgb(250,250,250)">=A0</=
span><span style=3D"font-family:monospace;font-size:10px;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">void</span><span style=3D"font-family:m=
onospace;font-size:10px;background-color:rgb(250,250,250)">=A0</span><span =
style=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,=
250);color:rgb(102,0,102)">Func</span><span style=3D"font-family:monospace;=
font-size:10px;background-color:rgb(250,250,250);color:rgb(102,102,0)">(</s=
pan><span style=3D"font-family:monospace;font-size:10px;background-color:rg=
b(250,250,250);color:rgb(0,0,136)">const</span><span style=3D"font-family:m=
onospace;font-size:10px;background-color:rgb(250,250,250)">=A0T=A0</span><s=
pan style=3D"font-family:monospace;font-size:10px;background-color:rgb(250,=
250,250);color:rgb(102,102,0)">&</span><span style=3D"font-family:monos=
pace;font-size:10px;background-color:rgb(250,250,250)">t</span><span style=
=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250);=
color:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;font-siz=
e:10px;background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;font-size:10px;background-color=
:rgb(250,250,250);color:rgb(102,102,0)">{</span><span style=3D"font-family:=
monospace;font-size:10px;background-color:rgb(250,250,250)"><br>=A0=A0</spa=
n><span style=3D"font-family:monospace;font-size:10px;background-color:rgb(=
250,250,250);color:rgb(0,0,136)">static</span><span style=3D"font-family:mo=
nospace;font-size:10px;background-color:rgb(250,250,250)">=A0</span><span s=
tyle=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,2=
50);color:rgb(0,0,136)">if</span><span style=3D"font-family:monospace;font-=
size:10px;background-color:rgb(250,250,250);color:rgb(102,102,0)">(</span><=
span style=3D"font-family:monospace;font-size:10px;background-color:rgb(250=
,250,250);color:rgb(136,0,0)">/*can call T::OptFunc*/</span><span style=3D"=
font-family:monospace;font-size:10px;background-color:rgb(250,250,250);colo=
r:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;font-size:10=
px;background-color:rgb(250,250,250)"><br>
=A0 =A0=A0__leak=A0</span><span style=3D"font-family:monospace;font-size:10=
px;background-color:rgb(250,250,250);color:rgb(0,0,136)">bool</span><span s=
tyle=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,2=
50)">=A0test=A0</span><span style=3D"font-family:monospace;font-size:10px;b=
ackground-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span styl=
e=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250)=
">=A0t</span><span style=3D"font-family:monospace;font-size:10px;background=
-color:rgb(250,250,250);color:rgb(102,102,0)">.</span><span style=3D"font-f=
amily:monospace;font-size:10px;background-color:rgb(250,250,250);color:rgb(=
102,0,102)">OptFunc</span><span style=3D"font-family:monospace;font-size:10=
px;background-color:rgb(250,250,250);color:rgb(102,102,0)">();</span><span =
style=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,=
250)"><br>
=A0=A0</span><span style=3D"font-family:monospace;font-size:10px;background=
-color:rgb(250,250,250);color:rgb(0,0,136)">else</span><span style=3D"font-=
family:monospace;font-size:10px;background-color:rgb(250,250,250)"><br>=A0 =
=A0=A0__leak=A0</span><span style=3D"font-family:monospace;font-size:10px;b=
ackground-color:rgb(250,250,250);color:rgb(0,0,136)">bool</span><span style=
=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250)"=
>=A0test=A0</span><span style=3D"font-family:monospace;font-size:10px;backg=
round-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span style=3D=
"font-family:monospace;font-size:10px;background-color:rgb(250,250,250)">=
=A0</span><span style=3D"font-family:monospace;font-size:10px;background-co=
lor:rgb(250,250,250);color:rgb(0,0,136)">true</span><span style=3D"font-fam=
ily:monospace;font-size:10px;background-color:rgb(250,250,250);color:rgb(10=
2,102,0)">;</span><span style=3D"font-family:monospace;font-size:10px;backg=
round-color:rgb(250,250,250)"><br>
<br>=A0=A0</span><span style=3D"font-family:monospace;font-size:10px;backgr=
ound-color:rgb(250,250,250);color:rgb(136,0,0)">//Do stuff with test.</span=
><span style=3D"font-family:monospace;font-size:10px;background-color:rgb(2=
50,250,250)"><br>
</span><span style=3D"font-family:monospace;font-size:10px;background-color=
:rgb(250,250,250);color:rgb(102,102,0)">}</span><br></div><div><br></div><d=
iv>Thinking about it, the problem you are trying to solve is not a problem =
concerning metaprogramming alone, but regular programming as well. It happe=
ns quite often that a user wants to chose between 2 (or more) ways to const=
ruct an object depending on a <b>runtime</b> condition. So it seems to me t=
hat it doesn't have to be strictly related to static if. You could appl=
y the same (ideally explicit) rules to regular if as well:</div>
<div><span style=3D"font-family:monospace;font-size:10px;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">template</span><span style=3D"font-fami=
ly:monospace;font-size:10px;background-color:rgb(250,250,250);color:rgb(102=
,102,0)"><</span><span style=3D"font-family:monospace;font-size:10px;bac=
kground-color:rgb(250,250,250);color:rgb(0,0,136)">typename</span><span sty=
le=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250=
)">=A0T</span><span style=3D"font-family:monospace;font-size:10px;backgroun=
d-color:rgb(250,250,250);color:rgb(102,102,0)">></span><span style=3D"fo=
nt-family:monospace;font-size:10px;background-color:rgb(250,250,250)">=A0</=
span><span style=3D"font-family:monospace;font-size:10px;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">void</span><span style=3D"font-family:m=
onospace;font-size:10px;background-color:rgb(250,250,250)">=A0</span><span =
style=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,=
250);color:rgb(102,0,102)">Func</span><span style=3D"font-family:monospace;=
font-size:10px;background-color:rgb(250,250,250);color:rgb(102,102,0)">(</s=
pan><span style=3D"font-family:monospace;font-size:10px;background-color:rg=
b(250,250,250);color:rgb(0,0,136)">const</span><span style=3D"font-family:m=
onospace;font-size:10px;background-color:rgb(250,250,250)">=A0T=A0</span><s=
pan style=3D"font-family:monospace;font-size:10px;background-color:rgb(250,=
250,250);color:rgb(102,102,0)">&</span><span style=3D"font-family:monos=
pace;font-size:10px;background-color:rgb(250,250,250)">t</span><span style=
=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250);=
color:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;font-siz=
e:10px;background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;font-size:10px;background-color=
:rgb(250,250,250);color:rgb(102,102,0)">{</span><span style=3D"font-family:=
monospace;font-size:10px;background-color:rgb(250,250,250)"><br>=A0=A0</spa=
n><span style=3D"font-family:monospace;font-size:10px;background-color:rgb(=
250,250,250);color:rgb(0,0,136)">if</span><span style=3D"font-family:monosp=
ace;font-size:10px;background-color:rgb(250,250,250);color:rgb(102,102,0)">=
(</span><span style=3D"font-family:monospace;font-size:10px;background-colo=
r:rgb(250,250,250);color:rgb(136,0,0)">/*any condition*/</span><span style=
=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250);=
color:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;font-siz=
e:10px;background-color:rgb(250,250,250)"><br>
=A0 =A0=A0__leak=A0</span><span style=3D"font-family:monospace;font-size:10=
px;background-color:rgb(250,250,250);color:rgb(0,0,136)">bool</span><span s=
tyle=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,2=
50)">=A0test=A0</span><span style=3D"font-family:monospace;font-size:10px;b=
ackground-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span styl=
e=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250)=
">=A0foo</span><span style=3D"font-family:monospace;font-size:10px;backgrou=
nd-color:rgb(250,250,250);color:rgb(102,102,0)">();</span><span style=3D"fo=
nt-family:monospace;font-size:10px;background-color:rgb(250,250,250)"><br>
=A0=A0</span><span style=3D"font-family:monospace;font-size:10px;background=
-color:rgb(250,250,250);color:rgb(0,0,136)">else</span><span style=3D"font-=
family:monospace;font-size:10px;background-color:rgb(250,250,250)"><br>=A0 =
=A0=A0__leak=A0</span><span style=3D"font-family:monospace;font-size:10px;b=
ackground-color:rgb(250,250,250);color:rgb(0,0,136)">bool</span><span style=
=3D"font-family:monospace;font-size:10px;background-color:rgb(250,250,250)"=
>=A0test=A0</span><span style=3D"font-family:monospace;font-size:10px;backg=
round-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span style=3D=
"font-family:monospace;font-size:10px;background-color:rgb(250,250,250)">=
=A0</span><span style=3D"font-family:monospace;font-size:10px;background-co=
lor:rgb(250,250,250);color:rgb(0,0,136)">true</span><span style=3D"font-fam=
ily:monospace;font-size:10px;background-color:rgb(250,250,250);color:rgb(10=
2,102,0)">;</span><span style=3D"font-family:monospace;font-size:10px;backg=
round-color:rgb(250,250,250)"><br>
<br>=A0=A0</span><span style=3D"font-family:monospace;font-size:10px;backgr=
ound-color:rgb(250,250,250);color:rgb(136,0,0)">//Do stuff with test.</span=
><span style=3D"font-family:monospace;font-size:10px;background-color:rgb(2=
50,250,250)"><br>
</span><span style=3D"font-family:monospace;font-size:10px;background-color=
:rgb(250,250,250);color:rgb(102,102,0)">}</span><br></div><div><br></div></=
div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0158c2920e49f704e3909271--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Sat, 10 Aug 2013 10:34:40 +0200
Raw View
> But the rules I suggested expressly forbid that. If one branch
> has it, then all branches must too. And it must be the same
> type.
>
I think one should allow not declaring the thing in a branch if the
scope outside the static if is left from the static if.
template<typename T> void Func(const T &t)
{
static if(/*can call T::OptFunc*/)
bool test = t.OptFunc();
else
return; // or throw something();
//Do stuff with test.
}
> What I don't like is the implicit nature of the rules you suggested. I
> would personally clearly prefer having to "mark" those names to
> indicate that they should leak. Such a marked name would then need to
> have an equivalent marked name in the other branch. Consider a __leak
> keyword for example (I know, the name of the keyword is bad but it is
> only to illustrate possible usage):
> template<typename T> void Func(const T &t)
> {
> static if(/*can call T::OptFunc*/)
> __leak bool test = t.OptFunc();
> else
> __leak bool test = true;
>
> //Do stuff with test.
> }
>
>
>
> Thinking about it, the problem you are trying to solve is not a
> problem concerning metaprogramming alone, but regular programming as
> well. It happens quite often that a user wants to chose between 2 (or
> more) ways to construct an object depending on a runtime condition. So
> it seems to me that it doesn't have to be strictly related to static
> if. You could apply the same (ideally explicit) rules to regular if as
> well:
> template<typename T> void Func(const T &t)
> {
> if(/*any condition*/)
> __leak bool test = foo();
> else
> __leak bool test = true;
>
> //Do stuff with test.
> }
>
I think the __leak idea is neat but how far should it be taken?
Should __leak be allowed in the declaration?
if (__leak Foo f(/* something */)) ; else return;
// do something with f
Should __leak be allowed in expressions and then generalize expressions?
if (!(__leak Foo f(/* something */))) return;
// do something with f
but also
int f = foo() + (__leak int g = bar());
// equivalent with: int g = bar(); int f = foo() + g;
Should __leak stack?
Note that this looks horrible but I have to break out of two if layers
here, this really need to be thought about .
if (/*something*/)
__leak bool test = foo();
else if (/* something else */)
// two __leak's to get out of two if scopes
__leak __leak bool test = bar();
else
__leak __leak bool test = gaz();
Should __leak be allowed on a break or continue?
while (/*condition*/) {
while (/*other condition*/) {
__leak break; // leaves the outer loop
}
}
Should __leak work in functions? (I am against this)
void f() {
__leak bool test = foo(); // declares a file scope variable
}
/MF
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: inkwizytoryankes@gmail.com
Date: Sun, 11 Aug 2013 04:59:04 -0700 (PDT)
Raw View
------=_Part_1145_33442795.1376222344821
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, August 10, 2013 5:23:36 AM UTC+2, Nicol Bolas wrote:
>
>
> Maybe you can enlighten me, but I fail to see what are the real advantages
>> of having a name "leak" out of its scope. The example you made could be the
>> following, which wouldn't require your special rules:
>>
>> template<typename T> void Func(const T &t)
>> {
>> bool test;
>> static if(/*can call T::OptFunc*/)
>> test = t.OptFunc();
>> else
>> test = true;
>>
>> //Do stuff with test.
>> }
>>
>> But maybe you can come up with another example that would show the
>> usefulness of what you are asking for?
>>
>
> You don't have to default construct `test`; that's the usefulness of it.
> Not every type is a boolean after all. Some types are expensive to default
> construct, and this avoid that. It's also a lot more natural for the user
> to initialize variables in situ than to create a default one and then fill
> it in after the fact.
>
This can be easy changed to:
bool test = func_with_static_if(t);
if you cant use default constructor. You could even use lambda if you dont
want pollute namespace.
--
---
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_1145_33442795.1376222344821
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 10, 2013 5:23:36 AM UTC+2, Nic=
ol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div>Maybe you can enlighten me, but I fail to see what=
are the real advantages of having a name "leak" out of its scope. The exam=
ple you made could be the following, which wouldn't require your special ru=
les:</div>
<div><br></div><div><span style=3D"font-family:monospace;background-color:r=
gb(250,250,250);color:rgb(0,0,136)">template</span><span style=3D"font-fami=
ly:monospace;background-color:rgb(250,250,250);color:rgb(102,102,0)"><</=
span><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
;color:rgb(0,0,136)">typename</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250)"> T</span><span style=3D"font-family:m=
onospace;background-color:rgb(250,250,250);color:rgb(102,102,0)">></span=
><span style=3D"font-family:monospace;background-color:rgb(250,250,250)">&n=
bsp;</span><span style=3D"font-family:monospace;background-color:rgb(250,25=
0,250);color:rgb(0,0,136)">void</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250)"> </span><span style=3D"font-family:=
monospace;background-color:rgb(250,250,250);color:rgb(102,0,102)">Func</spa=
n><span style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(102,102,0)"><wbr>(</span><span style=3D"font-family:monospace;backg=
round-color:rgb(250,250,250);color:rgb(0,0,136)">const</span><span style=3D=
"font-family:monospace;background-color:rgb(250,250,250)"> T </sp=
an><span style=3D"font-family:monospace;background-color:rgb(250,250,250);c=
olor:rgb(102,102,0)">&</span><span style=3D"font-family:monospace;backg=
round-color:rgb(250,250,250)">t</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250);color:rgb(102,102,0)">)</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-color:rgb(250,250,25=
0);color:rgb(102,102,0)">{</span></div><div><span style=3D"font-family:mono=
space;background-color:rgb(250,250,250)"><font color=3D"#666600"> boo=
l test;<br>
</font> </span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250);color:rgb(0,0,136)">static</span><span style=3D"font-=
family:monospace;background-color:rgb(250,250,250)"> </span><span styl=
e=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(0,0,=
136)">if</span><span style=3D"font-family:monospace;background-color:rgb(25=
0,250,250);color:rgb(102,102,0)">(</span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250);color:rgb(136,0,0)">/*can call T::OptF=
unc*/</span><span style=3D"font-family:monospace;background-color:rgb(250,2=
50,250);color:rgb(102,102,0)">)</span><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250)">test </span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250);color:rgb(102,102,0)">=3D</span><span s=
tyle=3D"font-family:monospace;background-color:rgb(250,250,250)"> t</s=
pan><span style=3D"font-family:monospace;background-color:rgb(250,250,250);=
color:rgb(102,102,0)">.</span><span style=3D"font-family:monospace;backgrou=
nd-color:rgb(250,250,250);color:rgb(102,0,102)">OptFunc</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250);color:rgb(102,1=
02,0)">();</span><span style=3D"font-family:monospace;background-color:rgb(=
250,250,250)"><br>
</span><span style=3D"font-family:monospace;background-color:rg=
b(250,250,250);color:rgb(0,0,136)">else</span><span style=3D"font-family:mo=
nospace;background-color:rgb(250,250,250)"><br> </span><s=
pan style=3D"font-family:monospace;background-color:rgb(250,250,250)">test&=
nbsp;</span><span style=3D"font-family:monospace;background-color:rgb(250,2=
50,250);color:rgb(102,102,0)">=3D</span><span style=3D"font-family:monospac=
e;background-color:rgb(250,250,250)"> </span><span style=3D"font-famil=
y:monospace;background-color:rgb(250,250,250);color:rgb(0,0,136)">true</spa=
n><span style=3D"font-family:monospace;background-color:rgb(250,250,250);co=
lor:rgb(102,102,0)">;</span><span style=3D"font-family:monospace;background=
-color:rgb(250,250,250)"><br>
<br> </span><span style=3D"font-family:monospace;background-colo=
r:rgb(250,250,250);color:rgb(136,0,0)">//Do stuff with test.</span><span st=
yle=3D"font-family:monospace;background-color:rgb(250,250,250)"><br></span>=
<span style=3D"font-family:monospace;background-color:rgb(250,250,250);colo=
r:rgb(102,102,0)">}</span><br>
</div><div><br></div><div>But maybe you can come up with another example th=
at would show the usefulness of what you are asking for?</div></div></div><=
/div></blockquote><div><br>You don't have to default construct `test`; that=
's the usefulness of it. Not every type is a boolean after all. Some types =
are expensive to default construct, and this avoid that. It's also a lot mo=
re natural for the user to initialize variables in situ than to create a de=
fault one and then fill it in after the fact.</div></div></blockquote><div>=
This can be easy changed to:<br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> test </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> func_with_static_if</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div>if you cant use default constructor. You could even use la=
mbda if you dont want pollute namespace.<br> <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1145_33442795.1376222344821--
.
Author: Alex B <devalexb@gmail.com>
Date: Sun, 11 Aug 2013 08:42:15 -0400
Raw View
--001a11c349266fd0e104e3ab563b
Content-Type: text/plain; charset=ISO-8859-1
>
>
> This can be easy changed to:
> bool test = func_with_static_if(t);
> if you cant use default constructor. You could even use lambda if you dont
> want pollute namespace.
>
The point of static if is, in appropriate contexts, to avoid having to
define several functions to perform the same task. Defining a specific
function just to initialize a variable goes against that spirit.
Also, concerning lambdas, it doesn't work since they are not constexpr.
--
---
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/.
--001a11c349266fd0e104e3ab563b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>This can be easy chang=
ed to:<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#008">bool</span><span style> test </span><span style=3D"=
color:#660">=3D</span><span style> func_with_static_if</span><span style=3D=
"color:#660">(</span><span style>t</span><span style=3D"color:#660">);</spa=
n><span style><br>
</span></div></code></div>if you cant use default constructor. You could ev=
en use lambda if you dont want pollute namespace.<br></div></div></blockquo=
te><div><br></div><div>The point of static if is, in appropriate contexts, =
to avoid having to define several functions to perform the same task. Defin=
ing a specific function just to initialize a variable goes against that spi=
rit.</div>
<div><br></div><div>Also, concerning lambdas, it doesn't work since the=
y are not constexpr.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c349266fd0e104e3ab563b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 11 Aug 2013 16:46:17 +0300
Raw View
--047d7bd766de6b8a4004e3ac3b7a
Content-Type: text/plain; charset=ISO-8859-1
On 11 August 2013 15:42, Alex B <devalexb@gmail.com> wrote:
>
>> This can be easy changed to:
>> bool test = func_with_static_if(t);
>> if you cant use default constructor. You could even use lambda if you
>> dont want pollute namespace.
>>
>
> The point of static if is, in appropriate contexts, to avoid having to
> define several functions to perform the same task. Defining a specific
> function just to initialize a variable goes against that spirit.
>
> Also, concerning lambdas, it doesn't work since they are not constexpr.
>
>
>
>
I have submitted an NB comment for C++14 to allow lambdas to be constexpr
when they can be, and I think I saw
an indication that there may be another such comment. With that in mind, I
would prefer holding the wacky
__leak ideas for a while.
--
---
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/.
--047d7bd766de6b8a4004e3ac3b7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 August 2013 15:42, Alex B <span dir=3D"ltr"><<a href=3D"ma=
ilto:devalexb@gmail.com" target=3D"_blank">devalexb@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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr"><br><div>This can be easy changed to:<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#008">bool</span><span> test </span><span style=3D"color:=
#660">=3D</span><span> func_with_static_if</span><span style=3D"color:#660"=
>(</span><span>t</span><span style=3D"color:#660">);</span><span><br>
</span></div></code></div>if you cant use default constructor. You could ev=
en use lambda if you dont want pollute namespace.<br></div></div></blockquo=
te><div><br></div></div><div>The point of static if is, in appropriate cont=
exts, to avoid having to define several functions to perform the same task.=
Defining a specific function just to initialize a variable goes against th=
at spirit.</div>
<div><br></div><div>Also, concerning lambdas, it doesn't work since the=
y are not constexpr.</div></div></div></div><div class=3D"HOEnZb"><div clas=
s=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I have submitted an NB=
comment for C++14 to allow lambdas to be constexpr when they can be, and I=
think I saw<br></div><div>an indication that there may be another such com=
ment.=A0 With that in mind, I would prefer holding the wacky<br>
</div><div>__leak ideas for a while.<br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bd766de6b8a4004e3ac3b7a--
.
Author: vattilah-groups@yahoo.co.uk
Date: Sun, 11 Aug 2013 07:24:33 -0700 (PDT)
Raw View
------=_Part_1676_29835060.1376231073722
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, 10 August 2013 04:23:36 UTC+1, Nicol Bolas wrote:
>
> On Friday, August 9, 2013 8:00:32 PM UTC-7, Alex B wrote:
>>
>> Maybe you can enlighten me, but I fail to see what are the real
>> advantages of having a name "leak" out of its scope. The example you made
>> could be the following, which wouldn't require your special rules:
>
>
>> template<typename T> void Func(const T &t)
>> {
>> bool test;
>> static if(/*can call T::OptFunc*/)
>> test = t.OptFunc();
>> else
>> test = true;
>>
>> //Do stuff with test.
>> }
>> [...]
>>
>
> You don't have to default construct `test`; that's the usefulness of it.
> Not every type is a boolean after all. Some types are expensive to default
> construct, and [allowing declarations to leak out of the static if
> scope] avoid that. It's also a lot more natural for the user to initialize
> variables in situ than to create a default one and then fill it in after
> the fact.
>
An alternative in this case could be to introduce a static version of the
ternary operator (?:), i.e. *statically conditional expressions*:
template<typename T> void Func(const T &t)
{
auto test = /*can call T::OptFunc*/ static? t.OptFunc() : true;
//Do stuff with test.
}
Interestingly, you might even consider relaxing the usual rule that both
sub-expressions need to evaluate to a common type, thus have the effect
that the type of the whole expression (and hence the variable testabove) is also conditional on the static condition.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1676_29835060.1376231073722
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, 10 August 2013 04:23:36 UTC+1, Nicol Bolas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div dir=3D"ltr">On Friday, August 9, 201=
3 8:00:32 PM UTC-7, Alex B wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;">Maybe you can=
enlighten me, but I fail to see what are the real advantages of having a n=
ame "leak" out of its scope. The example you made could be the following, w=
hich wouldn't require your special rules:</blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">
<div> </div><div><span style=3D"color: rgb(0, 0, 136); font-family: mo=
nospace; background-color: rgb(250, 250, 250);">template</span><span style=
=3D"color: rgb(102, 102, 0); font-family: monospace; background-color: rgb(=
250, 250, 250);"><</span><span style=3D"color: rgb(0, 0, 136); font-fami=
ly: monospace; background-color: rgb(250, 250, 250);">typename</span><span =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250);">&nb=
sp;T</span><span style=3D"color: rgb(102, 102, 0); font-family: monospace; =
background-color: rgb(250, 250, 250);">></span><span style=3D"font-famil=
y: monospace; background-color: rgb(250, 250, 250);"> </span><span sty=
le=3D"color: rgb(0, 0, 136); font-family: monospace; background-color: rgb(=
250, 250, 250);">void</span><span style=3D"font-family: monospace; backgrou=
nd-color: rgb(250, 250, 250);"> </span><span style=3D"color: rgb(102, =
0, 102); font-family: monospace; background-color: rgb(250, 250, 250);">Fun=
c</span><span style=3D"color: rgb(102, 102, 0); font-family: monospace; bac=
kground-color: rgb(250, 250, 250);"><wbr>(</span><span style=3D"color: rgb(=
0, 0, 136); font-family: monospace; background-color: rgb(250, 250, 250);">=
const</span><span style=3D"font-family: monospace; background-color: rgb(25=
0, 250, 250);"> T </span><span style=3D"color: rgb(102, 102, 0); =
font-family: monospace; background-color: rgb(250, 250, 250);">&</span>=
<span style=3D"font-family: monospace; background-color: rgb(250, 250, 250)=
;">t</span><span style=3D"color: rgb(102, 102, 0); font-family: monospace; =
background-color: rgb(250, 250, 250);">)</span><span style=3D"font-family: =
monospace; background-color: rgb(250, 250, 250);"><br>
</span><span style=3D"color: rgb(102, 102, 0); font-family: monospace; back=
ground-color: rgb(250, 250, 250);">{</span></div><div><span style=3D"font-f=
amily: monospace; background-color: rgb(250, 250, 250);"><font color=3D"#66=
6600"> bool test;<br>
</font> </span><span style=3D"color: rgb(0, 0, 136); font-family=
: monospace; background-color: rgb(250, 250, 250);">static</span><span styl=
e=3D"font-family: monospace; background-color: rgb(250, 250, 250);"> <=
/span><span style=3D"color: rgb(0, 0, 136); font-family: monospace; backgro=
und-color: rgb(250, 250, 250);">if</span><span style=3D"color: rgb(102, 102=
, 0); font-family: monospace; background-color: rgb(250, 250, 250);">(</spa=
n><span style=3D"color: rgb(136, 0, 0); font-family: monospace; background-=
color: rgb(250, 250, 250);">/*can call T::OptFunc*/</span><span style=3D"co=
lor: rgb(102, 102, 0); font-family: monospace; background-color: rgb(250, 2=
50, 250);">)</span><span style=3D"font-family: monospace; background-color:=
rgb(250, 250, 250);"><br>
</span><span style=3D"font-family: monospace; background=
-color: rgb(250, 250, 250);">test </span><span style=3D"color: rgb(102=
, 102, 0); font-family: monospace; background-color: rgb(250, 250, 250);">=
=3D</span><span style=3D"font-family: monospace; background-color: rgb(250,=
250, 250);"> t</span><span style=3D"color: rgb(102, 102, 0); font-fam=
ily: monospace; background-color: rgb(250, 250, 250);">.</span><span style=
=3D"color: rgb(102, 0, 102); font-family: monospace; background-color: rgb(=
250, 250, 250);">OptFunc</span><span style=3D"color: rgb(102, 102, 0); font=
-family: monospace; background-color: rgb(250, 250, 250);">();</span><span =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250);"><br=
>
</span><span style=3D"color: rgb(0, 0, 136); font-family: monos=
pace; background-color: rgb(250, 250, 250);">else</span><span style=3D"font=
-family: monospace; background-color: rgb(250, 250, 250);"><br>  =
; </span><span style=3D"font-family: monospace; background-color: rgb(=
250, 250, 250);">test </span><span style=3D"color: rgb(102, 102, 0); f=
ont-family: monospace; background-color: rgb(250, 250, 250);">=3D</span><sp=
an style=3D"font-family: monospace; background-color: rgb(250, 250, 250);">=
</span><span style=3D"color: rgb(0, 0, 136); font-family: monospace; =
background-color: rgb(250, 250, 250);">true</span><span style=3D"color: rgb=
(102, 102, 0); font-family: monospace; background-color: rgb(250, 250, 250)=
;">;</span><span style=3D"font-family: monospace; background-color: rgb(250=
, 250, 250);"><br>
<br> </span><span style=3D"color: rgb(136, 0, 0); font-family: m=
onospace; background-color: rgb(250, 250, 250);">//Do stuff with test.</spa=
n><span style=3D"font-family: monospace; background-color: rgb(250, 250, 25=
0);"><br></span><span style=3D"color: rgb(102, 102, 0); font-family: monosp=
ace; background-color: rgb(250, 250, 250);">}</span><br>
</div><div>[...]</div></div></div></div></blockquote><div><br>You don't hav=
e to default construct `test`; that's the usefulness of it. Not every type =
is a boolean after all. Some types are expensive to default construct, and&=
nbsp;[allowing declarations to leak out of the static if scope] avoid =
that. It's also a lot more natural for the user to initialize variables in =
situ than to create a default one and then fill it in after the fact.<br></=
div></div></blockquote><div> </div><div>An alternative in this case&nb=
sp;could be to introduce a static version of the ternary operator (?:), i.e=
.. <em>statically conditional expressions</em>: </div><div> </div>=
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><div><span style=3D"color: rgb(=
0, 0, 136); font-family: monospace; background-color: rgb(250, 250, 250);">=
<span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">templat=
e</span></span><span style=3D"color: rgb(102, 102, 0); font-family: monospa=
ce; background-color: rgb(250, 250, 250);"><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(102, 102, 0);"><</span></span><span style=3D"colo=
r: rgb(0, 0, 136); font-family: monospace; background-color: rgb(250, 250, =
250);"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">=
typename</span></span><span style=3D"font-family: monospace; background-col=
or: rgb(250, 250, 250);"><span class=3D"styled-by-prettify" style=3D"color:=
rgb(0, 0, 0);"> T</span></span><span style=3D"color: rgb(102, 102, 0); fon=
t-family: monospace; background-color: rgb(250, 250, 250);"><span class=3D"=
styled-by-prettify" style=3D"color: rgb(102, 102, 0);">></span></span><s=
pan style=3D"font-family: monospace; background-color: rgb(250, 250, 250);"=
><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span>=
</span><span style=3D"color: rgb(0, 0, 136); font-family: monospace; backgr=
ound-color: rgb(250, 250, 250);"><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 136);">void</span></span><span style=3D"font-family: m=
onospace; background-color: rgb(250, 250, 250);"><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 0);"> </span></span><span style=3D"color=
: rgb(102, 0, 102); font-family: monospace; background-color: rgb(250, 250,=
250);"><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 102)=
;">Func</span></span><span style=3D"color: rgb(102, 102, 0); font-family: m=
onospace; background-color: rgb(250, 250, 250);"><wbr><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);">(</span></span><span style=
=3D"color: rgb(0, 0, 136); font-family: monospace; background-color: rgb(25=
0, 250, 250);"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0,=
136);">const</span></span><span style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250);"><span class=3D"styled-by-prettify" style=3D"c=
olor: rgb(0, 0, 0);"> T </span></span><span style=3D"color: rgb(102, 102, 0=
); font-family: monospace; background-color: rgb(250, 250, 250);"><span cla=
ss=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">&</span></=
span><span style=3D"font-family: monospace; background-color: rgb(250, 250,=
250);"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">t=
</span></span><span style=3D"color: rgb(102, 102, 0); font-family: monospac=
e; background-color: rgb(250, 250, 250);"><span class=3D"styled-by-prettify=
" style=3D"color: rgb(102, 102, 0);">)</span></span><span style=3D"font-fam=
ily: monospace; background-color: rgb(250, 250, 250);"><span class=3D"style=
d-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span></span><span style=
=3D"color: rgb(102, 102, 0); font-family: monospace; background-color: rgb(=
250, 250, 250);"><span class=3D"styled-by-prettify" style=3D"color: rgb(102=
, 102, 0);">{</span></span></div><div><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250);"><font color=3D"#666600"><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><spa=
n class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">auto</span>=
<span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> test </s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">=
=3D</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"=
> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(136, 0, 0);=
">/*can call T::OptFunc*/</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"=
color: rgb(0, 0, 136);">static</span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 102, 0);">?</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(0, 0, 0);"> t</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(102, 102, 0);">.</span><span class=3D"styled-by-prettif=
y" style=3D"color: rgb(102, 0, 102);">OptFunc</span><span class=3D"styled-b=
y-prettify" style=3D"color: rgb(102, 102, 0);">()</span><span class=3D"styl=
ed-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(102, 102, 0);">:</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"sty=
led-by-prettify" style=3D"color: rgb(0, 0, 136);">true</span><span class=3D=
"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span></font></=
span><span style=3D"font-family: monospace; background-color: rgb(250, 250,=
250);"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">&=
nbsp; </span></span><span style=3D"color: rgb(136, 0, 0); font-family: mono=
space; background-color: rgb(250, 250, 250);"><span class=3D"styled-by-pret=
tify" style=3D"color: rgb(136, 0, 0);">//Do stuff with test.</span></span><=
span style=3D"font-family: monospace; background-color: rgb(250, 250, 250);=
"><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></s=
pan></span><span style=3D"color: rgb(102, 102, 0); font-family: monospace; =
background-color: rgb(250, 250, 250);"><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(102, 102, 0);">}</span></span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 0);"><br></span></div></div></code></div=
><div> </div><div>Interestingly, you might even consider relaxing=
the usual rule that both sub-expressions need to evaluate to a common type=
, thus have the effect that the type of the whole expression (and hence the=
variable <font face=3D"courier new,monospace">test</font> above) is a=
lso conditional on the static condition.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1676_29835060.1376231073722--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 11 Aug 2013 14:57:32 -0700 (PDT)
Raw View
------=_Part_1827_8430084.1376258253049
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, August 11, 2013 10:24:33 PM UTC+8, vattila...@yahoo.co.uk wrote:
>
> Interestingly, you might even consider relaxing the usual rule that both
> sub-expressions need to evaluate to a common type, thus have the effect
> that the type of the whole expression (and hence the variable testabove) is also conditional on the static condition.
>
Sounds nice in principle, but consider what it would do to e.g. the
specification of std::common_type. The conditional operator is already used
to perform type computation, which such a change would quietly suppress.
--
---
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_1827_8430084.1376258253049
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, August 11, 2013 10:24:33 PM UTC+8, vatt=
ila...@yahoo.co.uk wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">Interestingly, you might even consider relaxing the usual =
rule that both sub-expressions need to evaluate to a common type, thus have=
the effect that the type of the whole expression (and hence the variable <=
font face=3D"courier new,monospace">test</font> above) is also conditi=
onal on the static condition.<br></div></blockquote><div><br>Sounds nice in=
principle, but consider what it would do to e.g. the specification of std:=
:common_type. The conditional operator is already used to perform type comp=
utation, which such a change would quietly suppress.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1827_8430084.1376258253049--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 11 Aug 2013 15:55:00 -0700
Raw View
--001a11c20990c4bf7f04e3b3e5a9
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Aug 11, 2013 at 2:57 PM, David Krauss <potswa@gmail.com> wrote:
>
>
> On Sunday, August 11, 2013 10:24:33 PM UTC+8, vattila...@yahoo.co.ukwrote:
>>
>> Interestingly, you might even consider relaxing the usual rule that both
>> sub-expressions need to evaluate to a common type, thus have the effect
>> that the type of the whole expression (and hence the variable testabove) is also conditional on the static condition.
>>
>
> Sounds nice in principle, but consider what it would do to e.g. the
> specification of std::common_type. The conditional operator is already used
> to perform type computation, which such a change would quietly suppress.
>
common_type would presumably continue to use "?:" rather than "static?:",
so would be unchanged.
--
---
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/.
--001a11c20990c4bf7f04e3b3e5a9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 11, 2013 at 2:57 PM, David Krauss <span dir=3D"ltr"><<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></sp=
an> wrote:<br><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"><div class=3D"im"><br><br>On Sunday, August 11, 2013 10:24=
:33 PM UTC+8, <a href=3D"mailto:vattila...@yahoo.co.uk" target=3D"_blank">v=
attila...@yahoo.co.uk</a> wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Interestingly,=A0you might even consider relaxing the usua=
l rule that both sub-expressions need to evaluate to a common type, thus ha=
ve the effect that the type of the whole expression (and hence the variable=
<font face=3D"courier new,monospace">test</font> above)=A0is also conditio=
nal on the static condition.<br>
</div></blockquote></div><div><br>Sounds nice in principle, but consider wh=
at it would do to e.g. the specification of std::common_type. The condition=
al operator is already used to perform type computation, which such a chang=
e would quietly suppress.</div>
</div></blockquote><div><br></div><div>common_type would presumably continu=
e to use "?:" rather than "static?:", so would be uncha=
nged.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c20990c4bf7f04e3b3e5a9--
.
Author: tortoise741@gmail.com
Date: Thu, 8 Aug 2013 03:26:46 -0700 (PDT)
Raw View
------=_Part_127_6107380.1375957606592
Content-Type: text/plain; charset=ISO-8859-1
C++ is a multi-paradigm language. I'm not sure that template
meta-programming lends itself well to being anything other than
functional. However, to my mind the biggest problem with the template
programming is not that its functional but that the syntax
is horrendously ugly due to the angle brackets. You will see many cases of
people describing template algorithms in
Haskell and translating them by hand. E.g.
http://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/
If we could improve the syntax there it would go all way to helping people
reach the original posters engineer level 3.
On Tuesday, 30 July 2013 11:01:03 UTC+1, R. Martinho Fernandes wrote:
>
> On Mon, Jul 29, 2013 at 11:50 PM, Brian Anderle <whatta...@gmail.com<javascript:>>
> wrote:
> >
> > It is not that this lets us to do something we could not before, but
> rather
> > lets us do it in a way that mirrors the way we are used to coding and
> should
> > help bridge the gap to getting more programmers, myself included, into
> group
> > 3.
> >
>
> I am used to coding in a functional way and also want the non-template
> parts of the language to let me do things in a way that mirrors the
> way I am used to coding.
>
--
---
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_127_6107380.1375957606592
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>C++ is a multi-paradigm language. I'm not sure that template meta-progr=
amming lends itself well to being anything other than<br>functional. Howeve=
r, to my mind the biggest problem with the template programming is not that=
its functional but that the syntax<br>is horrendously ugly due to the angl=
e brackets. You will see many cases of people describing template algorithm=
s in<br>Haskell and translating them by hand. E.g. http://bartoszmilewski.c=
om/2009/10/21/what-does-haskell-have-to-do-with-c/<br><br>If we could impro=
ve the syntax there it would go all way to helping people reach the origina=
l posters engineer level 3.<br><br>On Tuesday, 30 July 2013 11:01:03 UTC+1,=
R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
On Mon, Jul 29, 2013 at 11:50 PM, Brian Anderle <<a href=3D"javascript:"=
target=3D"_blank" gdf-obfuscated-mailto=3D"hagwuKWtI_UJ">whatta...@gmail.c=
om</a>> wrote:
<br>>
<br>> It is not that this lets us to do something we could not before, b=
ut rather
<br>> lets us do it in a way that mirrors the way we are used to coding =
and should
<br>> help bridge the gap to getting more programmers, myself included, =
into group
<br>> 3.
<br>>
<br>
<br>I am used to coding in a functional way and also want the non-template
<br>parts of the language to let me do things in a way that mirrors the
<br>way I am used to coding.
<br></blockquote>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_127_6107380.1375957606592--
.