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

Hi,

I have a document, not a proposal, that I'd like to submit to the C++
standard committee for consideration.  The document examines the
undesirable run-time characteristics of certain constexpr functions.  It
then explores four different options for adjusting the standard to manage
these undesirable characteristics.  It does not make a recommendation for
which of the four options should be pursued.

If it makes a difference, Walter E. Brown has reviewed the document and
said that he thinks it is good enough for submission to the committee.

The document is available at:

https://docs.google.com/open?id=0B0-xyi_NILkZeUxCWjdudW52UjQ

I hope that the document meets with your approval.  If not, I'd appreciate
any suggestions you may have for adjustments that I should make.

Thanks for your time.

Scott Schurr
S.Scott.Schurr@gmail.com

--




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

<div dir=3D"ltr"><div><div>Hi,<br><br></div>I have a document, not a propos=
al, that I&#39;d like to submit to the C++ standard committee for considera=
tion.=A0 The document examines the undesirable run-time characteristics of =
certain constexpr functions.=A0 It then explores four different options for=
 adjusting the standard to manage these undesirable characteristics.=A0 It =
does not make a recommendation for which of the four options should be purs=
ued.<br>
<br></div><div>If it makes a difference, Walter E. Brown has reviewed the d=
ocument and said that he thinks it is good enough for submission to the com=
mittee.<br></div><div><br></div>The document is available at:<br><br><a hre=
f=3D"https://docs.google.com/open?id=3D0B0-xyi_NILkZeUxCWjdudW52UjQ">https:=
//docs.google.com/open?id=3D0B0-xyi_NILkZeUxCWjdudW52UjQ</a><br clear=3D"al=
l">
<div><div><div><br></div><div>I hope that the document meets with your appr=
oval.=A0 If not, I&#39;d appreciate any suggestions you may have for adjust=
ments that I should make.<br><br></div><div>Thanks for your time.<br></div>
<div><br>Scott Schurr<br><a href=3D"mailto:S.Scott.Schurr@gmail.com">S.Scot=
t.Schurr@gmail.com</a><br><br>
</div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f23549dfb021004d2997472--

.

On Sun, Jan 6, 2013 at 1:14 AM, Scott Schurr <s.scott.schurr@gmail.com> wrote:
> The document is available at:
>
> https://docs.google.com/open?id=0B0-xyi_NILkZeUxCWjdudW52UjQ

Interesting.

Personally, I prefer the 2nd approach, since when the traits being
combined with `static if`, we even can write different implementations
for one constexpr function/ctor, thus the advantage of 1 and 4 are
included.  About the approach 2, it's not worth to break the C++11
practices, but it's valuable to define the tail recursion.

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

--




.

------=_Part_379_25663307.1357464514927
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, January 5, 2013 11:14:01 PM UTC-8, Scott Schurr wrote:
>
> Hi,
>
> I have a document, not a proposal, that I'd like to submit to the C++
> standard committee for consideration.  The document examines the
> undesirable run-time characteristics of certain constexpr functions.  It
> then explores four different options for adjusting the standard to manage
> these undesirable characteristics.  It does not make a recommendation for
> which of the four options should be pursued.
>
> If it makes a difference, Walter E. Brown has reviewed the document and
> said that he thinks it is good enough for submission to the committee.
>
> The document is available at:
>
> https://docs.google.com/open?id=0B0-xyi_NILkZeUxCWjdudW52UjQ
>
> I hope that the document meets with your approval.  If not, I'd appreciate
> any suggestions you may have for adjustments that I should make.
>
> Thanks for your time.
>

Option #1:

First, let's get the syntactic issue out of the way: no attributes. I'm with
Herb on this; attributes should never affect actual behavior<http://herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/>.
If you want something that affects behavior, make it a special identifier
or keyword or something.

More importantly, without some form of overloading, you have to do
something specifically at the call site to pick the efficient version. That
is very counter-intuitive for the user, as well as often requiring
meaningless parameters and such.

Option #2:

I don't think #2 is going to fly. The committee is already looking into
ways to expand the capabilities of constexpr functions with multiple
statements and so forth. Having them curtail this by allowing only tail
recursion seems rather counter-productive to the goal of allowing constexpr
functions to be more expressive.

Also, I'm not convinced that recursion is the only problem with running the
compile-time version at runtime. It seems a very narrow view of the
problem. A view that will become increasingly more narrow as we start
allowing constexpr functions to be more complex.

Option #3:

The traits thing doesn't seem very viable; it feels like a library solution
to a language problem.

Option #4:

This seems to be the most effective solution. It uses the best grammar (ie:
none). It's intuitive, effectively being a part of overload resolution. The
fact that which function is to be called is indeterminate is, to my mind,
not a big problem. It would only be a problem if the user is abusing
contexpr overloading to implement a function in a completely different way.

Indeed, I would much rather they tighten up when constexpr will be actually
constexpr's, instead of keeping it loose and building weak grammatical
structures on top of that.

--




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

<br><br>On Saturday, January 5, 2013 11:14:01 PM UTC-8, Scott Schurr wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div>Hi,=
<br><br></div>I have a document, not a proposal, that I'd like to submit to=
 the C++ standard committee for consideration.&nbsp; The document examines =
the undesirable run-time characteristics of certain constexpr functions.&nb=
sp; It then explores four different options for adjusting the standard to m=
anage these undesirable characteristics.&nbsp; It does not make a recommend=
ation for which of the four options should be pursued.<br>
<br></div><div>If it makes a difference, Walter E. Brown has reviewed the d=
ocument and said that he thinks it is good enough for submission to the com=
mittee.<br></div><div><br></div>The document is available at:<br><br><a hre=
f=3D"https://docs.google.com/open?id=3D0B0-xyi_NILkZeUxCWjdudW52UjQ" target=
=3D"_blank">https://docs.google.com/open?<wbr>id=3D0B0-xyi_<wbr>NILkZeUxCWj=
dudW52UjQ</a><br clear=3D"all">
<div><div><div><br></div><div>I hope that the document meets with your appr=
oval.&nbsp; If not, I'd appreciate any suggestions you may have for adjustm=
ents that I should make.<br><br></div><div>Thanks for your time.<br></div><=
/div></div></div></blockquote><div><br>Option #1:<br><br>First, let's get t=
he syntactic issue out of the way: no attributes. I'm <a href=3D"http://her=
bsutter.com/2012/04/02/reader-qa-keywords-and-attributes/">with Herb on thi=
s; attributes should never affect actual behavior</a>. If you want somethin=
g that affects behavior, make it a special identifier or keyword or somethi=
ng.<br><br>More importantly, without some form of overloading, you have to =
do something specifically at the call site to pick the efficient version. T=
hat is very counter-intuitive for the user, as well as often requiring mean=
ingless parameters and such.<br><br>Option #2:<br><br>I don't think #2 is g=
oing to fly. The committee is already looking into ways to expand the capab=
ilities of constexpr functions with multiple statements and so forth. Havin=
g them curtail this by allowing only tail recursion seems rather counter-pr=
oductive to the goal of allowing constexpr functions to be more expressive.=
<br><br>Also, I'm not convinced that recursion is the only problem with run=
ning the compile-time version at runtime. It seems a very narrow view of th=
e problem. A view that will become increasingly more narrow as we start all=
owing constexpr functions to be more complex.<br><br>Option #3:<br><br>The =
traits thing doesn't seem very viable; it feels like a library solution to =
a language problem.<br><br>Option #4:<br><br>This seems to be the most effe=
ctive solution. It uses the best grammar (ie: none). It's intuitive, effect=
ively being a part of overload resolution. The fact that which function is =
to be called is indeterminate is, to my mind, not a big problem. It would o=
nly be a problem if the user is abusing contexpr overloading to implement a=
 function in a completely different way.<br><br>Indeed, I would much rather=
 they tighten up when constexpr will be actually constexpr's, instead of ke=
eping it loose and building weak grammatical structures on top of that.<br>=
</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_379_25663307.1357464514927--

.

------=_Part_124_18477566.1357469485490
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, January 6, 2013 8:14:01 AM UTC+1, Scott Schurr wrote:
>
> I have a document, not a proposal, that I'd like to submit to the C++
> standard committee for consideration.  The document examines the
> undesirable run-time characteristics of certain constexpr functions.  It
> then explores four different options for adjusting the standard to manage
> these undesirable characteristics.  It does not make a recommendation for
> which of the four options should be pursued.
>
> If it makes a difference, Walter E. Brown has reviewed the document and
> said that he thinks it is good enough for submission to the committee.
>
> The document is available at:
>
> https://docs.google.com/open?id=0B0-xyi_NILkZeUxCWjdudW52UjQ
>

Just making sure: you know that code like the following compiles? (well, it
may depend on adding constexpr to std::array, but that's a given)

#include <array>
constexpr int f(int const *p, int n, int sum = 0) {
  return (n == 0) ? sum : f(p + 1, n - 1, sum + *p);
}
constexpr std::array<int, 3> a = { 4, 5, 6};
constexpr int sum = f(&a[0],3);
static_assert ( sum == 15, "Huh?" );

Some of your remarks are QoI issues. Some compilers use constexpr as an
incentive to try and evaluate a function at compile-time if they know the
arguments, but it isn't an all or nothing situation, most optimizations are
heuristics.

One reason people want constexpr-only functions is so they can use the
function arguments as constants, as template parameters.

--




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

On Sunday, January 6, 2013 8:14:01 AM UTC+1, Scott Schurr wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I have a document, =
not a proposal, that I'd like to submit to the C++ standard committee for c=
onsideration.&nbsp; The document examines the undesirable run-time characte=
ristics of certain constexpr functions.&nbsp; It then explores four differe=
nt options for adjusting the standard to manage these undesirable character=
istics.&nbsp; It does not make a recommendation for which of the four optio=
ns should be pursued.<br>
<br></div><div>If it makes a difference, Walter E. Brown has reviewed the d=
ocument and said that he thinks it is good enough for submission to the com=
mittee.<br></div><div><br></div>The document is available at:<br><br><a hre=
f=3D"https://docs.google.com/open?id=3D0B0-xyi_NILkZeUxCWjdudW52UjQ" target=
=3D"_blank">https://docs.google.com/open?<wbr>id=3D0B0-xyi_<wbr>NILkZeUxCWj=
dudW52UjQ</a><br></div></blockquote><div><br>Just making sure: you know tha=
t code like the following compiles? (well, it may depend on adding constexp=
r to std::array, but that's a given)<br>&nbsp;<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;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #800;" class=3D"styled-by-prettify">#include</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cl=
ass=3D"styled-by-prettify">&lt;array&gt;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</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"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">const</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">p</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"> n</s=
pan><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"> sum </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=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-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><s=
pan 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: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">n </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> sum </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">p </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: #066;" class=3D"styled-by-prettify">1<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> n </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">-</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;"=
 class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> sum </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">p</span><span style=
=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: #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"st=
yled-by-prettify">constexpr</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">array</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</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: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> a </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: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">4</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: #0=
66;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">6</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">constexpr</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> sum </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(&amp;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">],</spa=
n><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">static_assert</span><span style=3D"col=
or: #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"> sum </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">15</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: #080;" class=3D"styled-by-prettify">"Huh?"</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: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Some of=
 your remarks are QoI issues. Some compilers use constexpr as an incentive =
to try and evaluate a function at compile-time if they know the arguments, =
but it isn't an all or nothing situation, most optimizations are heuristics=
..<br><br>One reason people want constexpr-only functions is so they can use=
 the function arguments as constants, as template parameters.<br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_124_18477566.1357469485490--

.

On Sat, 5 Jan 2013, Scott Schurr wrote:

> Hi,
>=20
> I have a document, not a proposal, that I'd like to submit to the C++ sta=
ndard committee for consideration.=A0 The document examines the undesirable=
 run-time
> characteristics of certain constexpr functions.=A0 It then explores four =
different options for adjusting the standard to manage these undesirable
> characteristics.=A0 It does not make a recommendation for which of the fo=
ur options should be pursued.
>=20
> If it makes a difference, Walter E. Brown has reviewed the document and s=
aid that he thinks it is good enough for submission to the committee.
>=20
> The document is available at:
>=20
> https://docs.google.com/open?id=3D0B0-xyi_NILkZeUxCWjdudW52UjQ
>=20
> I hope that the document meets with your approval.=A0 If not, I'd appreci=
ate any suggestions you may have for adjustments that I should make.
>=20
> Thanks for your time.

I agree with your concerns about constexpr.  Another place where similar=20
issues arise is in writing a constexpr function that truly requires that=20
its arguments are known at compile-time (for example, by using them as=20
template arguments or in static_assert).  This is desirable, and people=20
have asked how to do it:

http://stackoverflow.com/questions/9045635/c11-constexpr-functions-argument=
-passed-in-template-argument

http://stackoverflow.com/questions/9789913/how-to-tell-static-assert-that-c=
onstexpr-function-arguments-are-const

http://stackoverflow.com/questions/12233393/constexpr-vs-template-for-compi=
le-time-maths-functions

and the limitation (as shown in the third link) means that some=20
metaprograms must still be written as templates to get error checking,=20
even when they otherwise would be allowed to be constexpr functions.  It=20
may make sense to combine the issues that you are concerned about with=20
overloading on whether particular function arguments are truly=20
compile-time constants, which I have heard discussion of in the committee,=
=20
and whether to allow things like a constexpr function whose return type=20
depends on the values of its compile-time arguments (as requested in=20
http://www.mofeel.net/1176-comp-std-c++/2065.aspx; note that this is=20
currently possible to do with templates but not constexpr).

-- Jeremiah Willcock

--=20




.

Publishing a document that benchmarks a program with no optimization
makes you look like a noob. Don't do it, unless you include a good
argument that debug performance matters in the benchmarked code.
Speculating about bad compiler implementations isn't convincing: users
should pick a better compiler or push their vendor to incorporate
optimizations from the open source alternatives. There _are_ cases
where constexpr code hurts optimized performance, e.g. strlen() and
memcmp(), or can cause stack overflows in debug mode, and it would be
helpful to include those cases.

This paper could use an abstract summarizing the problem you're
attacking and the solutions you examine. Otherwise it's hard to tell
whether I care enough to read 27 pages. Unlike a lot of writing, your
introduction shouldn't leave me in suspense. ;)

Richard Smith proposed (somewhere) an is_constexpr(arg) function that
could be tested in an if() statement to select different code paths
for constant vs runtime evaluations. It would be helpful to include
that as an alternative to your "trait" section.

Jeffrey

On Sun, Jan 6, 2013 at 7:14 AM, Scott Schurr <s.scott.schurr@gmail.com> wrote:
> Hi,
>
> I have a document, not a proposal, that I'd like to submit to the C++
> standard committee for consideration.  The document examines the undesirable
> run-time characteristics of certain constexpr functions.  It then explores
> four different options for adjusting the standard to manage these
> undesirable characteristics.  It does not make a recommendation for which of
> the four options should be pursued.
>
> If it makes a difference, Walter E. Brown has reviewed the document and said
> that he thinks it is good enough for submission to the committee.
>
> The document is available at:
>
> https://docs.google.com/open?id=0B0-xyi_NILkZeUxCWjdudW52UjQ
>
> I hope that the document meets with your approval.  If not, I'd appreciate
> any suggestions you may have for adjustments that I should make.
>
> Thanks for your time.
>
> Scott Schurr
> S.Scott.Schurr@gmail.com
>
> --
>
>
>

--




.

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

Hi Nicol and Marc,

Thanks very much for taking the time to look over and comment on the paper.

Nicol, while I very much appreciate your positions on the various options,
I'm not inclined to remove any of them from the paper.  None of the options
are perfect (as we both noted).  I believe that different people have
affinities for different options based, at least in part, on the direction
they'd like to see the language go.  Your comment...

> Indeed, I would much rather they tighten up when constexpr
> will be actually constexpr's, instead of keeping it loose and
> building weak grammatical structures on top of that.

is very much in line with my personal thinking.  I'm not sure that the
constexpr problems brought up in the paper are sufficient to justify
changes of that nature.  But perhaps these issues in combination with other
concerns might be enough to push the language that way.

What I'm really hoping for is that someone will see the four options and
say, "You missed one."  And that will be the option that works really
well.  I'm also hoping that folks reading the paper will say, "I understand
your concern, and I have the following additional concerns..."  Then any
changes can try to take all of the concerns into account, not just the ones
I raised.

Marc, you noted...
> Just making sure: you know that code like the following compiles?...

Thanks.  No, I didn't know about that.  I guess that means I'll need to
re-work my example and remove my griping about code bloat.  I'll certainly
do that.  Thanks very much for the pointer.  It will take me a while to
rework the paper.  Hopefully I can get a new version up by the end of next
weekend.

> Some of your remarks are QoI issues. Some compilers use
> constexpr as an incentive to try and evaluate a function at
> compile-time if they know the arguments, but it isn't an all or
> nothing situation, most optimizations are heuristics.

Thanks.  You're reinforcing the view that I have taken with regard to
constexpr.  And I think most of the time using constexpr to drive those
heuristics works just fine.  But there are a few select constexpr functions
or constructors (e.g., those involving deep recursion) where those
heuristics can go awry.  I'm hoping to find a way to manage the specific
functions that can go sour without messing up all of the good that
constexpr does.

Thanks again to both of you for looking over and commenting on the paper.
I'll do my best to put up a revised version in about a week.

Scott Schurr
S.Scott.Schurr@gmail.com

--




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

<div dir=3D"ltr"><div><div>Hi Nicol and Marc,<br><br></div>Thanks very much=
 for taking the time to look over and comment on the paper.<br><br></div>Ni=
col, while I very much appreciate your positions on the various options, I&=
#39;m not inclined to remove any of them from the paper.=A0 None of the opt=
ions are perfect (as we both noted).=A0 I believe that different people hav=
e affinities for different options based, at least in part, on the directio=
n they&#39;d like to see the language go.=A0 Your comment...<br>

<br>&gt; Indeed, I would much rather they tighten up when constexpr<br>&gt;=
 will be=20
actually constexpr&#39;s, instead of keeping it loose and<br>&gt; building =
weak=20
grammatical structures on top of that.<br><br><div>is very much in line wit=
h my personal thinking.=A0 I&#39;m not sure that the constexpr problems bro=
ught up in the paper are sufficient to justify changes of that nature.=A0 B=
ut perhaps these issues in combination with other concerns might be enough =
to push the language that way.<br>

</div><div><br></div><div>What I&#39;m really hoping for is that someone wi=
ll see the four options and say, &quot;You missed one.&quot;=A0 And that wi=
ll be the option that works really well.=A0 I&#39;m also hoping that folks =
reading the paper will say, &quot;I understand your concern, and I have the=
 following additional concerns...&quot;=A0 Then any changes can try to take=
 all of the concerns into account, not just the ones I raised.<br>
</div><div><br></div><div>Marc, you noted...<br>&gt; Just making sure: you =
know that code like the following compiles?...<br><br></div><div>Thanks.=A0=
 No, I didn&#39;t know about that.=A0 I guess that means I&#39;ll need to r=
e-work my example and remove my griping about code bloat.=A0 I&#39;ll certa=
inly do that.=A0 Thanks very much for the pointer.=A0 It will take me a whi=
le to rework the paper.=A0 Hopefully I can get a new version up by the end =
of next weekend.<br>
</div><div><br>&gt; Some of your remarks are QoI issues. Some compilers use=
<br>&gt; constexpr as an=20
incentive to try and evaluate a function at<br>&gt; compile-time if they kn=
ow=20
the arguments, but it isn&#39;t an all or<br>&gt; nothing situation, most=
=20
optimizations are heuristics.<br><br></div><div>Thanks.=A0 You&#39;re reinf=
orcing the view that I have taken with regard to constexpr.=A0 And I think =
most of the time using constexpr to drive those heuristics works just fine.=
=A0 But there are a few select constexpr functions or constructors (e.g., t=
hose involving deep recursion) where those heuristics can go awry.=A0 I&#39=
;m hoping to find a way to manage the specific functions that can go sour w=
ithout messing up all of the good that constexpr does.<br>
<div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Thanks=
 again to both of you for looking over and commenting on the paper.=A0 I&#3=
9;ll do my best to put up a revised version in about a week.<br></div><div =
class=3D"gmail_extra">
<br>Scott Schurr<br><a href=3D"mailto:S.Scott.Schurr@gmail.com" target=3D"_=
blank">S.Scott.Schurr@gmail.com</a><br><br>
</div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f23549d48241704d2ab8680--

.

------=_Part_48_9224811.1357569785016
Content-Type: text/plain; charset=ISO-8859-1

I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0
code, and I walked away. That's just meaningless.

--




------=_Part_48_9224811.1357569785016
Content-Type: text/html; charset=ISO-8859-1

I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0 code, and I walked away. That's just meaningless.

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_48_9224811.1357569785016--

.

------=_Part_751_31575248.1357580212975
Content-Type: text/plain; charset=ISO-8859-1

On Monday, January 7, 2013 3:43:05 PM UTC+1, DeadMG wrote:

> I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0
> code, and I walked away. That's just meaningless.


Is it? People do run -O0 code and if it's an order of magnitude slower than
it should be this matters.

--




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

On Monday, January 7, 2013 3:43:05 PM UTC+1, DeadMG wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">I agree with Jeffrey. I was reading the pap=
er, I saw you benchmarked -O0 code, and I walked away. That's just meaningl=
ess.</blockquote><div><br></div><div>Is it? People do run -O0 code and if i=
t's an order of magnitude slower than it should be this matters.&nbsp;</div=
>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_751_31575248.1357580212975--

.

------=_Part_315_7210767.1357580333465
Content-Type: text/plain; charset=ISO-8859-1

It matters so much, they could just recompile this function in another
object file at -O2 and be fine.

--




------=_Part_315_7210767.1357580333465
Content-Type: text/html; charset=ISO-8859-1

It matters so much, they could just recompile this function in another object file at -O2 and be fine.

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_315_7210767.1357580333465--

.

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

Hi Olaf and DeadMG,

Thanks for your consideration of the paper.

On Mon, Jan 7, 2013 at 9:36 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Monday, January 7, 2013 3:43:05 PM UTC+1, DeadMG wrote:
>
>> I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0
>> code, and I walked away. That's just meaningless.
>
>
> Is it? People do run -O0 code and if it's an order of magnitude slower
> than it should be this matters.
>

Personally, I think that timing -O0 code is useful because it gives me a
view of what the standard allows me to express.  I'm writing a paper aimed
at the standard, not at optimizers.  I think there are two points to
consider here:

 1. No optimizations are mandated by the standard.  Each compiler will
optimize differently.  There is nothing in the standard that specifies how
optimizations should be performed.  In that way -O0 code is the closest to
what the standard itself has to say.

 2. Later in the paper I took the same code, optimized it at -O3, and timed
it.  The size of the improvement for the constexpr code (executed at
run-time) was much greater than the speed improvement of non-constexpr
code.  Naively, I usually expect speed improvements from the optimizer to
be relatively uniform across a program.  That was not the case here.  There
is nothing in the standard that says I can expect the same level of
improvement from a compiler other than g++.

Thanks again for your thoughts.

Scott Schurr
S.Scott.Schurr@gmail.com

--




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

<div dir=3D"ltr"><div class=3D"gmail_extra">Hi Olaf and DeadMG,<br><br></di=
v><div class=3D"gmail_extra">Thanks for your consideration of the paper.<br=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Ja=
n 7, 2013 at 9:36 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Monday, January 7, 2013=
 3:43:05 PM UTC+1, DeadMG wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0 co=
de, and I walked away. That&#39;s just meaningless.</blockquote><div><br></=
div></div><div>Is it? People do run -O0 code and if it&#39;s an order of ma=
gnitude slower than it should be this matters.=A0</div>
</blockquote></div><br></div><div class=3D"gmail_extra">Personally, I think=
 that timing -O0 code is useful because it gives me a view of what the stan=
dard allows me to express.=A0 I&#39;m writing a paper aimed at the standard=
, not at optimizers.=A0 I think there are two points to consider here:<br>
<br></div><div class=3D"gmail_extra">=A01. No optimizations are mandated by=
 the standard.=A0 Each compiler will optimize differently.=A0 There is noth=
ing in the standard that specifies how optimizations should be performed.=
=A0 In that way -O0 code is the closest to what the standard itself has to =
say.<br>
<br></div><div class=3D"gmail_extra">=A02. Later in the paper I took the sa=
me code, optimized it at -O3, and timed it.=A0 The size of the improvement =
for the constexpr code (executed at run-time) was much greater than the spe=
ed improvement of non-constexpr code.=A0 Naively, I usually expect speed im=
provements from the optimizer to be relatively uniform across a program.=A0=
 That was not the case here.=A0 There is nothing in the standard that says =
I can expect the same level of improvement from a compiler other than g++.<=
br clear=3D"all">
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Thank=
s again for your thoughts.<br></div><div class=3D"gmail_extra"><br>Scott Sc=
hurr<br><a href=3D"mailto:S.Scott.Schurr@gmail.com">S.Scott.Schurr@gmail.co=
m</a><br>
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--f46d0447a12dae811c04d2b6ad02--

.

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

On Mon, Jan 7, 2013 at 6:36 PM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Monday, January 7, 2013 3:43:05 PM UTC+1, DeadMG wrote:
>
>> I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0
>> code, and I walked away. That's just meaningless.
>
>
> Is it? People do run -O0 code and if it's an order of magnitude slower
> than it should be this matters.
>


I guess it depends on the domain.
In my work domain (involving soft-real-time), having fast "debug" (Visual
Studio) can be critical to be able to hunt  some kind of bugs
( because the application is unusable otherwise and reproducting bugs
become impossible without correct user input timing).
It is usual to use "Release Debug", that is optimized code still with debug
informations.
Unfortunately, in such case, most inlined code, implicitely or explicitely,
loose debug information anyway, so if you use performant code you loose the
ability to debug it without tracing on release.
I know some former colleagues who would avoid using template code where
possible for this specific reason.
These last years I worked on less demanding apps which helped me using
Debug mode through all the development, but that's because it was on PC,
not on some embedded device like before.

I don't know if a lot of people are in the cases where they need to work a
lot with unoptimized code,
but I guess it's good to know that there are some people that do.

Also, I'm not sure what gcc/clang args corresponds exactly compared to
Visual Studio (which is the compiler I know best so far),
so take this input with distance.

I'm not informed enough to comment on the paper, the recursion-only
limitation seems to be the root of the potential performance problem to me,
but I'm no expert
and didn't use constexpr yet.

Joel Lamotte

--




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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Mon, Jan 7, 2013 at 6:36 PM, Olaf van der Spek <span dir=3D"ltr">&lt=
;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail=
..com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Monday, January 7, 2013 3:43:05 PM U=
TC+1, DeadMG wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

I agree with Jeffrey. I was reading the paper, I saw you benchmarked -O0 co=
de, and I walked away. That&#39;s just meaningless.</blockquote><div><br></=
div></div><div>Is it? People do run -O0 code and if it&#39;s an order of ma=
gnitude slower than it should be this matters.=A0</div>

</blockquote></div><br></div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">I guess it depends on the domain.</div><div class=3D"gmai=
l_extra">In my work domain (involving soft-real-time), having fast &quot;de=
bug&quot; (Visual Studio) can be critical to be able to hunt =A0some kind o=
f bugs=A0</div>
<div class=3D"gmail_extra">( because the application is unusable otherwise =
and reproducting bugs become impossible without correct user input timing).=
<br>
It is usual to use &quot;Release Debug&quot;, that is optimized code still =
with debug informations.=A0</div><div class=3D"gmail_extra">Unfortunately, =
in such case, most inlined code, implicitely or explicitely, loose debug in=
formation anyway, so if you use performant code you loose the ability to de=
bug it without tracing on release.<br>
I know some former colleagues who would avoid using template code where pos=
sible for this specific reason.</div><div class=3D"gmail_extra">These last =
years I worked on less demanding apps which helped me using Debug mode thro=
ugh all the development, but that&#39;s because it was on PC, not on some e=
mbedded device like before.<br>
<br>I don&#39;t know if a lot of people are in the cases where they need to=
 work a lot with unoptimized code,=A0</div><div class=3D"gmail_extra">but I=
 guess it&#39;s good to know that there are some people that do.</div><div =
class=3D"gmail_extra" style>
<br>Also, I&#39;m not sure what gcc/clang args corresponds exactly compared=
 to Visual Studio (which is the compiler I know best so far),<br></div><div=
 class=3D"gmail_extra" style>so take this input with distance.</div><div cl=
ass=3D"gmail_extra" style>
<br></div><div class=3D"gmail_extra" style>I&#39;m not informed enough to c=
omment on the paper, the recursion-only limitation seems to be the root of =
the potential performance problem to me, but I&#39;m no expert=A0</div><div=
 class=3D"gmail_extra" style>
and didn&#39;t use constexpr yet.</div><div class=3D"gmail_extra" style><br=
></div><div class=3D"gmail_extra" style>Joel Lamotte</div><div class=3D"gma=
il_extra" style><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8fb2044673116d04d2b88fe3--

.

On 1/7/13, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:
> On Jan 7, 2013 Olaf van der Spek <olafvdspek@gmail.com> wrote:
> > On Monday, January 7, 2013 3:43:05 PM UTC+1, DeadMG wrote:
> > > I agree with Jeffrey. I was reading the paper, I saw
> > > you benchmarked -O0 code, and I walked away. That's just
> > > meaningless.
> >
> > Is it? People do run -O0 code and if it's an order of magnitude
> > slower than it should be this matters.
>
> I don't know if a lot of people are in the cases where they need
> to work a lot with unoptimized code, but I guess it's good to
> know that there are some people that do.

Different programmers have different needs.  The programmers
should be selecting a compiler vendor that meets their needs.
I doubt the committee would try to make guarantees here, with the
possible exception of requiring an optimization for tail recursion
(as opposed to requiring the code to be tail recursive).

> I'm not informed enough to comment on the paper, the recursion-only
> limitation seems to be the root of the potential performance
> problem to me, but I'm no expert and didn't use constexpr yet.

Please keep in mind that the current restrictions on the body of
constexpr functions is there because we thought everyone could
implement it and it was the minimum necessary.  It is not that way
because we thought nothing more was useful.  We expected to relax
the restrictions so as to permit richer functions.  Some of that
has already happened.  Before we start worrying about optimizing
recursion, we should ask if we can support loops in constexpr
functions.  It might be tricky, but it might be better than several
other choices.

--=20
Lawrence Crowl

--=20




.

On Sun, Jan 6, 2013 at 9:02 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> Publishing a document that benchmarks a program with no optimization
> makes you look like a noob. Don't do it, unless you include a good
> argument that debug performance matters in the benchmarked code.
> Speculating about bad compiler implementations isn't convincing: users
> should pick a better compiler or push their vendor to incorporate
> optimizations from the open source alternatives. There _are_ cases
> where constexpr code hurts optimized performance, e.g. strlen() and
> memcmp(), or can cause stack overflows in debug mode, and it would be
> helpful to include those cases.

+1

IMO, the most convincing benchmarks in a committee document are those
that show both unoptimized and optimized results, and show them for
several compilers. For example, recent versions of GCC, Clang, and
VC++

> This paper could use an abstract summarizing the problem you're
> attacking and the solutions you examine. Otherwise it's hard to tell
> whether I care enough to read 27 pages. Unlike a lot of writing, your
> introduction shouldn't leave me in suspense. ;)

+1

> Richard Smith proposed (somewhere) an is_constexpr(arg) function that
> could be tested in an if() statement to select different code paths
> for constant vs runtime evaluations. It would be helpful to include
> that as an alternative to your "trait" section.

+1

--Beman

--




.

Lawrence Crowl <crowl@googlers.com> writes:

[...]

|                        Before we start worrying about optimizing
| recursion, we should ask if we can support loops in constexpr
| functions.  It might be tricky, but it might be better than several
| other choices.

Amen.

--
Gabriel Dos Reis, http://www.axiomatics.org/~gdr/

--




.

On Tue, Jan 8, 2013 at 9:16 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> Lawrence Crowl <crowl@googlers.com> writes:
>
> [...]
>
> |                        Before we start worrying about optimizing
> | recursion, we should ask if we can support loops in constexpr
> | functions.  It might be tricky, but it might be better than several
> | other choices.
>
> Amen.

Even when we support loops in constexpr functions, we'll still have to
deal with functions like strlen(), memcmp(), etc. that want to
optimize the _loops_ when executed at runtime.

--




.

Jeffrey Yasskin <jyasskin@googlers.com> writes:

| On Tue, Jan 8, 2013 at 9:16 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| > Lawrence Crowl <crowl@googlers.com> writes:
| >
| > [...]
| >
| > |                        Before we start worrying about optimizing
| > | recursion, we should ask if we can support loops in constexpr
| > | functions.  It might be tricky, but it might be better than several
| > | other choices.
| >
| > Amen.
|
| Even when we support loops in constexpr functions, we'll still have to
| deal with functions like strlen(), memcmp(), etc. that want to
| optimize the _loops_ when executed at runtime.

The confusion about strlen() and memcmp() is primarily profond and
perplexing implementors' confusion.
That was one of the most confusing things that happened at the Portland
meeting.  Sadly, it is being perpetuated.

There are real fundamental issues that need to be looked at seriously,
without shouting match and tweetter-style design.  But, we no near that yet.
I promised a paper for Bristol, it will be there.

--
Gabriel Dos Reis, http://www.axiomatics.org/~gdr/

--




.

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

Hi,

I submitted a paper for your consideration on January 5th.  I got a number
of useful comments back.  In my estimation the most important comment came
from Marc Glisse.

On Sun, Jan 6, 2013 at 8:47 PM, Scott Schurr <s.scott.schurr@gmail.com>wrote:

> Marc, you noted...
> > Just making sure: you know that code like the following compiles?...
>
> Thanks.  No, I didn't know about that.  I guess that means I'll need to
> re-work my example and remove my griping about code bloat.  I'll certainly
> do that.  Thanks very much for the pointer.  It will take me a while to
> rework the paper.  Hopefully I can get a new version up by the end of next
> weekend.
>

I've now re-worked the paper given Marc's information. The motivating
example now uses std::array, and I've attempted to remove all references to
code bloat, since using std:array removes that issue.

As Marc also noted, in most cases constexpr code does not have negative
consequences when invoked at runtime.  I've attempted to make more of a nod
to that truth.

I've also added more timing results with optimization set at -O3, since
that was a concern in two of the comments.

Although the example has changed slightly, the primary thrust of the paper
remains the same.

For those who are interested, a pdf of the revised paper can be seen at:

https://docs.google.com/file/d/0B0-xyi_NILkZS1dZZnFlOE9fYmc/edit

Thanks again for your time.

Scott Schurr
S.Scott.Schurr@gmail.com

--




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

<div dir=3D"ltr"><div class=3D"gmail_extra" style>Hi,</div><div class=3D"gm=
ail_extra" style><br></div><div class=3D"gmail_extra" style>I submitted a p=
aper for your consideration on January 5th. =A0I got a number of useful com=
ments back. =A0In my estimation the most important comment came from Marc <=
span class=3D"" style>Glisse</span>.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Sun, Jan 6, 2013 at 8:47 PM, Scott <span class=3D"" sty=
le>Schurr</span> <span dir=3D"ltr">&lt;<a href=3D"mailto:s.scott.schurr@gma=
il.com" target=3D"_blank">s.<span class=3D"" style>scott</span>.<span class=
=3D"" style>schurr</span>@gmail.com</a>&gt;</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>Marc, you noted...<br>&gt; Just making sure: you know=
 that code like the following compiles?...<br>
<br></div><div>Thanks.=A0 No, I didn&#39;t know about that.=A0 I guess that=
 means I&#39;ll need to re-work my example and remove my griping about code=
 bloat.=A0 I&#39;ll certainly do that.=A0 Thanks very much for the pointer.=
=A0 It will take me a while to rework the paper.=A0 Hopefully I can get a n=
ew version up by the end of next weekend.<br>

</div><div class=3D"im"><div></div></div></blockquote></div><br>I&#39;ve no=
w re-worked the paper given Marc&#39;s information. The motivating example =
now uses std::array, and I&#39;ve attempted to remove all references to cod=
e bloat, since using std:array removes that issue.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>As Ma=
rc also noted, in most cases <span class=3D"" style>constexpr</span> code d=
oes not have negative consequences when invoked at <span class=3D"" style>r=
untime</span>. =A0I&#39;ve attempted to make more of a nod to that truth.</=
div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra">I&#39=
;ve also added more timing results with optimization set at -O3, since that=
 was a concern in two of the comments. =A0</div><div class=3D"gmail_extra">=
<br>
</div><div class=3D"gmail_extra">Although the example has changed slightly,=
 the primary thrust of the paper remains the same.</div><div class=3D"gmail=
_extra"><br></div><div class=3D"gmail_extra">For those who are interested, =
a <span class=3D"" style>pdf</span> of the revised paper can be seen at:</d=
iv>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><a href=3D"=
https://docs.google.com/file/d/0B0-">https://docs.google.com/file/d/0B0-</a=
><span class=3D"" style>xyi</span>_NILkZS1dZZnFlOE9fYmc/edit<br><br clear=
=3D"all">
<div style>Thanks again for your time.</div><br>Scott <span class=3D"" styl=
e>Schurr</span><br>S.Scott.<span class=3D"" style>Schurr</span>@<a href=3D"=
http://gmail.com">gmail.com</a>
</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--20cf303f64ea02191604d337001d--

.

------=_Part_119_5260167.1359226977158
Content-Type: text/plain; charset=ISO-8859-1


First of all, I think option 4 is the best. The most simple syntax that
does the job. During dubugging, just comment one out at test the other one.
To be honest, benchmarks don't mean much to me here. There are many
different algorithms that we can write, which can be optimised differently.
One thing is for sure: sometimes I would like to have two options. For
evaluation at compile time, the function has to be simple (there is a limit
on the depth of the recursion in the standard, by the way) and I may not
use is for complicated calculations anyway. For execution, I need
more a robust function that executes well in all circumstances, possibly
with no recursion. As the standard stands at present, you may use
only one version of the function.  Look at the arithmetic functions: if I
provide a compile time function, it has to be recursive.

To sum up, we need the ability to be able to write two versions of a
function (compile-time and execution-time) and option #4 is the best.

Thanks Scott for a good article.



--

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



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

<div>&nbsp;</div><div>First of all, I think option 4 is the best. The most =
simple syntax that does the job. During dubugging, just comment one out at =
test the other one.</div><div>To be honest, benchmarks don't mean much to m=
e here. There are many different algorithms that we can write, which can be=
 optimised differently.</div><div>One thing is for sure: sometimes I would =
like to&nbsp;have two options. For evaluation at compile time, the function=
 has to be simple (there is a limit</div><div>on the depth of the recursion=
&nbsp;in the standard, by the way) and I may not use is for complicated cal=
culations anyway. For execution, I need</div><div>more a robust function th=
at&nbsp;executes well in all circumstances, possibly with no recursion. As =
the standard stands at present, you may use</div><div>only one version of t=
he function.&nbsp; Look at the arithmetic functions:&nbsp;if I provide a co=
mpile time function, it has to be recursive.</div><div>&nbsp;</div><div>To =
sum up, we need&nbsp;the ability&nbsp;to be able to write two versions of a=
 function (compile-time and&nbsp;execution-time) and option #4 is the best.=
&nbsp;</div><div>&nbsp;</div><div>Thanks Scott for a good article.</div><di=
v>&nbsp;</div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_119_5260167.1359226977158--

.

------=_Part_203_23161169.1359291421298
Content-Type: text/plain; charset=ISO-8859-1

I don't think that Option 4 is an especially good idea. How many extra
overloads are we going to have to write?

I would prefer

1. Force compilers to evaluate constexpr function calls at translation time
if they can be.
2. Change constexpr functions so that the range of programming techniques
they can employ is much wider than now.

--

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



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

I don't think that Option 4 is an especially good idea. How many extra over=
loads are we going to have to write?<div><br></div><div>I would prefer</div=
><div><br></div><div>1. Force compilers to evaluate constexpr function call=
s at translation time if they can be.</div><div>2. Change constexpr functio=
ns so that the range of programming techniques they can employ is much wide=
r than now.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_203_23161169.1359291421298--

.

On Sun, Jan 27, 2013 at 1:57 PM, DeadMG <wolfeinstein@gmail.com> wrote:
> I don't think that Option 4 is an especially good idea. How many extra
> overloads are we going to have to write?
>
> I would prefer
>
> 1. Force compilers to evaluate constexpr function calls at translation time
> if they can be.

What if they can't?
Like said before, the optimal implementation for compile-time
evaluation may differ greatly from run-time evaluation.




--
Olaf

--

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



.

------=_Part_90_7724024.1359294650690
Content-Type: text/plain; charset=ISO-8859-1

That's what #2 is for. The very fact that you might want to have two
different implementations for compile and run time is plain wrong. If
compile-time functionality is too limited to handle optimized run-time
code, then expand it until it isn't.

--

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



------=_Part_90_7724024.1359294650690
Content-Type: text/html; charset=ISO-8859-1

That's what #2 is for. The very fact that you might want to have two different implementations for compile and run time is plain wrong. If compile-time functionality is too limited to handle optimized run-time code, then expand it until it isn't.

<p></p>

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

------=_Part_90_7724024.1359294650690--

.

On Sun, Jan 27, 2013 at 5:50 AM, DeadMG <wolfeinstein@gmail.com> wrote:
> That's what #2 is for. The very fact that you might want to have two
> different implementations for compile and run time is plain wrong. If
> compile-time functionality is too limited to handle optimized run-time code,
> then expand it until it isn't.

I don't think we can have a meaningful discussion about this until we
see Gaby Dos Reis' promised paper. I hope that paper addresses
assembly implementations.

--

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



.

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

You don't need much analysis/discussion for option #4: just adopt it.

On 28 January 2013 04:28, Jeffrey Yasskin <jyasskin@googlers.com> wrote:

> On Sun, Jan 27, 2013 at 5:50 AM, DeadMG <wolfeinstein@gmail.com> wrote:
> > That's what #2 is for. The very fact that you might want to have two
> > different implementations for compile and run time is plain wrong. If
> > compile-time functionality is too limited to handle optimized run-time
> code,
> > then expand it until it isn't.
>
> I don't think we can have a meaningful discussion about this until we
> see Gaby Dos Reis' promised paper. I hope that paper addresses
> assembly implementations.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To post to this group, send email to std-proposals@isocpp.org.
> To unsubscribe from this group, send email to
> std-proposals+unsubscribe@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

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



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

You don&#39;t need much analysis/discussion for option #4: just adopt it.<b=
r><br>
<div class=3D"gmail_quote">On 28 January 2013 04:28, Jeffrey Yasskin <span =
dir=3D"ltr">&lt;<a href=3D"mailto:jyasskin@googlers.com" target=3D"_blank">=
jyasskin@googlers.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PA=
DDING-LEFT:1ex" class=3D"gmail_quote">
<div class=3D"im">On Sun, Jan 27, 2013 at 5:50 AM, DeadMG &lt;<a href=3D"ma=
ilto:wolfeinstein@gmail.com">wolfeinstein@gmail.com</a>&gt; wrote:<br>&gt; =
That&#39;s what #2 is for. The very fact that you might want to have two<br=
>
&gt; different implementations for compile and run time is plain wrong. If<=
br>&gt; compile-time functionality is too limited to handle optimized run-t=
ime code,<br>&gt; then expand it until it isn&#39;t.<br><br></div>I don&#39=
;t think we can have a meaningful discussion about this until we<br>
see Gaby Dos Reis&#39; promised paper. I hope that paper addresses<br>assem=
bly implementations.<br>
<div class=3D"HOEnZb">
<div class=3D"h5"><br>--<br><br>---<br>You received this message because yo=
u are subscribed to the Google Groups &quot;ISO C++ Standard - Future Propo=
sals&quot; group.<br>To post to this group, send email to <a href=3D"mailto=
:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
To unsubscribe from this group, send email to <a href=3D"mailto:std-proposa=
ls%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>V=
isit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/s=
td-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp.=
org/group/std-proposals/?hl=3Den</a>.<br>
<br><br></div></div></blockquote></div><br>

<p></p>

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

--e89a8f643104e19e0804d47dec96--

.

------=_Part_145_9428241.1362979266804
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,

Thanks to everyone that commented on the previous revisions of the
document.  I've taken some time to consider all of the earlier comments.  As
a consequence I have yet another revision available for your consideration.

I took to heart comments from Jeffrey Yaskin and DeadMG that execution
speed would not be a winning argument.  So this revision focuses on finding
errors during compilation rather than at run time.  Execution speed is still
considered, but takes second seat.

This new revision is available at:

  https://docs.google.com/file/d/0B0-xyi_NILkZTk1WSjhsNllIbmc/edit

The bulk of the changes are at the beginning of the paper which provides
motivation for adjusting constexpr.  The analysis of the four approaches to
adjusting constexpr remains comparatively unchanged.

Unless someone notes a significant flaw in the paper, I intend to submit it
in the next few days.

For those with sufficient curiosity, the previous revision of the paper is
still available here:

  https://docs.google.com/file/d/0B0-xyi_NILkZS1dZZnFlOE9fYmc/edit

Thanks very much to everyone for all of the help and comments.

Scott Schurr

--

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



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

<div>Hi everyone,</div><div><br></div><div>Thanks to everyone that commente=
d on the previous revisions of the&nbsp;</div><div>document. &nbsp;I've tak=
en some time to consider all of the earlier comments. &nbsp;As</div><div>a =
consequence I have yet another revision available for your consideration.</=
div><div><br></div><div>I took to heart comments from Jeffrey Yaskin and De=
adMG that execution</div><div>speed would not be a winning argument. &nbsp;=
So this revision focuses on finding</div><div>errors during compilation rat=
her than at run time. &nbsp;Execution speed is still</div><div>considered, =
but takes second seat.</div><div><br></div><div>This new revision is availa=
ble at:</div><div><br></div><div>&nbsp; https://docs.google.com/file/d/0B0-=
xyi_NILkZTk1WSjhsNllIbmc/edit</div><div><br></div><div>The bulk of the chan=
ges are at the beginning of the paper which provides</div><div>motivation f=
or adjusting constexpr. &nbsp;The analysis of the four approaches to</div><=
div>adjusting constexpr remains comparatively unchanged.</div><div><br></di=
v><div>Unless someone notes a significant flaw in the paper, I intend to su=
bmit it</div><div>in the next few days.</div><div><br></div><div>For those =
with sufficient curiosity, the previous revision of the paper is</div><div>=
still available here:</div><div><br></div><div>&nbsp; https://docs.google.c=
om/file/d/0B0-xyi_NILkZS1dZZnFlOE9fYmc/edit</div><div><br></div><div>Thanks=
 very much to everyone for all of the help and comments.</div><div><br></di=
v><div>Scott Schurr</div><div><br></div>

<p></p>

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

------=_Part_145_9428241.1362979266804--

.

2013/3/11  <s.scott.schurr@gmail.com>:
> Hi everyone,
>
> Thanks to everyone that commented on the previous revisions of the
> document.  I've taken some time to consider all of the earlier comments.  As
> a consequence I have yet another revision available for your consideration.

I would like to remind that if you want to have your proposal in the
upcoming emailing list, you should send your document until the end of
this week to the library chair,

lwgchair@gmail.com

- Daniel

> I took to heart comments from Jeffrey Yaskin and DeadMG that execution
> speed would not be a winning argument.  So this revision focuses on finding
> errors during compilation rather than at run time.  Execution speed is still
> considered, but takes second seat.
>
> This new revision is available at:
>
>   https://docs.google.com/file/d/0B0-xyi_NILkZTk1WSjhsNllIbmc/edit
>
> The bulk of the changes are at the beginning of the paper which provides
> motivation for adjusting constexpr.  The analysis of the four approaches to
> adjusting constexpr remains comparatively unchanged.
>
> Unless someone notes a significant flaw in the paper, I intend to submit it
> in the next few days.
>
> For those with sufficient curiosity, the previous revision of the paper is
> still available here:
>
>   https://docs.google.com/file/d/0B0-xyi_NILkZS1dZZnFlOE9fYmc/edit
>
> Thanks very much to everyone for all of the help and comments.
>
> Scott Schurr
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

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



.

------=_Part_1659_12610759.1363753134225
Content-Type: text/plain; charset=ISO-8859-1

On Monday, March 11, 2013 1:21:06 AM UTC-4, s.scott...@gmail.com wrote:
>
> Unless someone notes a significant flaw in the paper, I intend to submit it
> in the next few days.
>

I just read the version of the paper distributed with the mailing, and I
have one major concern. In the analysis in section 9.4, you appear to have
overlooked the ability to use the = delete idiom on arbitrary functions.
The run-time version can simply be reduced to:

template <typename T> bool during_compilation_with_arg(T arg) = delete;

which has the added benefit of also catching edge cases like attempting to
take a function pointer. The issue of overload resolution is a sticky one,
but I think that there is some merit to at least discussing a cop-out such
as only doing constexpr/non-constexpr resolution after all other overload
resolution (basically, perform overload resolution, and if the result is a
set of ambiguous candidates that are identical in signature except one is
constexpr and the other is not, then the appropriate one is selected based
on evaluation at compile-time or run-time).

Sean

--

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



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

On Monday, March 11, 2013 1:21:06 AM UTC-4, s.scott...@gmail.com wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div>Unless someone notes a signif=
icant flaw in the paper, I intend to submit it</div><div>in the next few da=
ys.</div></blockquote><div><br></div><div>I just read the version of the pa=
per distributed with the mailing, and I have one major concern. In the anal=
ysis in section 9.4, you appear to have overlooked the ability to use the =
=3D delete idiom on arbitrary functions. The run-time version can simply be=
 reduced to:</div><div><br></div><div><div>template &lt;typename T&gt; bool=
 during_compilation_with_arg(T arg) =3D delete;</div></div><div><br></div><=
div>which has the added benefit of also catching edge cases like attempting=
 to take a function pointer. The issue of overload resolution is a sticky o=
ne, but I think that there is some merit to at least discussing a cop-out s=
uch as only doing constexpr/non-constexpr resolution after all other overlo=
ad resolution (basically, perform overload resolution, and if the result is=
 a set of ambiguous candidates that are identical in signature except one i=
s constexpr and the other is not, then the appropriate one is selected base=
d on evaluation at compile-time or run-time).</div><div><br></div><div>Sean=
</div>

<p></p>

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

------=_Part_1659_12610759.1363753134225--

.

------=_Part_229_17425210.1363799686204
Content-Type: text/plain; charset=ISO-8859-1

Hi Sean,

Thanks for reading the paper.

On Tuesday, March 19, 2013 9:18:54 PM UTC-7, Sean Hunt wrote:
>
> I just read the version of the paper distributed with the mailing, and I
> have one major concern. In the analysis in section 9.4, you appear to have
> overlooked the ability to use the = delete idiom on arbitrary functions.
> The run-time version can simply be reduced to:
>
> template <typename T> bool during_compilation_with_arg(T arg) = delete;
>
> which has the added benefit of also catching edge cases like attempting to
> take a function pointer. The issue of overload resolution is a sticky one,
> but I think that there is some merit to at least discussing a cop-out such
> as only doing constexpr/non-constexpr resolution after all other overload
> resolution (basically, perform overload resolution, and if the result is a
> set of ambiguous candidates that are identical in signature except one is
> constexpr and the other is not, then the appropriate one is selected based
> on evaluation at compile-time or run-time).
>
> Sean
>

I like your suggestion that "= delete" could be used to remove the
non-constexpr overload of a function.  If I'm understanding you correctly,
then the example in section 9.4 would no longer need to be use templates,
since we would no longer be using SFINAE to side-step undesired compilation
errors.  The entire example would collapse to...

    // The compile-time only function that we want...
    constexpr bool during_compilation_with_arg(bool arg)
    {
        return arg;
    }

    // The run-time version that we want to forbid...
    bool during_compilation_with_arg(bool arg) = delete;

 I think that's elegant and really easy to explain.  Thank you very much
for pointing out that approach.

I also like the approach you suggest for handling overload resolution.  I'm
not a compiler writer, but I appreciate the complexities compilers face
when handling overload resolution.  Changes to overload resolution need to
result in a set of rules that a human (as well as a machine) can reason
about.

Thanks again for reading.

Scott Schurr

--

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



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

Hi Sean,<div><br></div><div>Thanks for reading the paper.<br><br>On Tuesday=
, March 19, 2013 9:18:54 PM UTC-7, Sean Hunt wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div>I just read the version of the paper distributed =
with the mailing, and I have one major concern. In the analysis in section =
9.4, you appear to have overlooked the ability to use the =3D delete idiom =
on arbitrary functions. The run-time version can simply be reduced to:</div=
><div><br></div><div><div>template &lt;typename T&gt; bool during_compilati=
on_with_arg(T arg) =3D delete;</div></div><div><br></div><div>which has the=
 added benefit of also catching edge cases like attempting to take a functi=
on pointer. The issue of overload resolution is a sticky one, but I think t=
hat there is some merit to at least discussing a cop-out such as only doing=
 constexpr/non-constexpr resolution after all other overload resolution (ba=
sically, perform overload resolution, and if the result is a set of ambiguo=
us candidates that are identical in signature except one is constexpr and t=
he other is not, then the appropriate one is selected based on evaluation a=
t compile-time or run-time).</div><div><br></div><div>Sean</div></blockquot=
e><div><br></div><div>I like your suggestion that "=3D delete" could be use=
d to remove the non-constexpr overload of a function. &nbsp;If I'm understa=
nding you correctly, then the example in section 9.4 would no longer need t=
o be use templates, since we would no longer be using SFINAE to side-step u=
ndesired compilation errors. &nbsp;The entire example would collapse to...<=
/div><div><br></div><div><div><font face=3D"courier new, monospace">&nbsp; =
&nbsp; // The compile-time only function that we want...</font></div><div><=
div><font face=3D"courier new, monospace">&nbsp; &nbsp; constexpr bool duri=
ng_compilation_with_arg(bool arg)</font></div><div><font face=3D"courier ne=
w, monospace">&nbsp; &nbsp; {</font></div><div><font face=3D"courier new, m=
onospace">&nbsp; &nbsp; &nbsp; &nbsp; return arg;</font></div><div><font fa=
ce=3D"courier new, monospace">&nbsp; &nbsp; }</font></div></div><div><font =
face=3D"courier new, monospace"><br></font></div><div><font face=3D"courier=
 new, monospace">&nbsp; &nbsp; // The run-time version that we want to forb=
id...</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; =
bool during_compilation_with_arg(bool arg) =3D delete;</font></div><div><br=
></div></div><div>&nbsp;I think that's elegant and really easy to explain. =
&nbsp;Thank you very much for pointing out that approach.</div></div><div><=
br></div><div>I also like the approach you suggest for handling overload re=
solution. &nbsp;I'm not a compiler writer, but I appreciate the complexitie=
s compilers face when handling overload resolution. &nbsp;Changes to overlo=
ad resolution need to result in a set of rules that a human (as well as a m=
achine) can reason about.</div><div><br></div><div>Thanks again for reading=
..</div><div><br></div><div>Scott Schurr</div><div><br></div>

<p></p>

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

------=_Part_229_17425210.1363799686204--

.