------=_Part_1668_2908975.1386433835717
Content-Type: text/plain; charset=ISO-8859-1

Sort of
related: https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/constexpr-specified$20loop$20variable/std-proposals/vseNksuBviI/I043vaXf8LIJ

I proposed a constexpr-specified loop variable would logically unroll and
instantiate the loop sub-statement, which would work in both compile-time
and run-time functions (constexpr functions or normal functions).


On Saturday, December 7, 2013 5:31:43 AM UTC+1, Mark wrote:
>
> I've been toying around with the relaxed constexpr rules of C++14 in an
> SVN build of clang. The thought occurred to me that I might be able to use
> the 'natural' syntax of a for loop to iterate over the contents in a
> std::tuple at compile-time in a constexpr function. This seems conceptually
> plausible, as I am now allowed to loop over a range at compile-time, but as
> I found out on Stack Overflow<http://stackoverflow.com/questions/20436611/possible-to-instantiate-templates-using-a-for-loop-in-a-c14-constexpr-function>,
> when speaking strict standardese, I cannot instantiate a template (like
> std::get) with my loop variable because the variable is not constexpr, even
> though it is part of a constexpr function.
>
> A simplified example:
>
> template<int N>
> constexpr int foo() {
>   return N;
> }
>
> constexpr int getSum() {
>   auto sum = 0;
>   for (auto i = 0; i < 10; ++i) {
>     sum += foo<i>(); //The interesting part
>   }
>   return sum;
> }
>
> constexpr auto sum = getSum();
>
>
>
>
> I'd like to open discussion as to whether or not it makes sense to allow
> this.
>
>
> I should also clarify, I understand that constexpr functions can be
> invoked at runtime. I am not talking about that case; there are already
> cases where constexpr functions fail to compile only when used for runtime
> invocations, I would extend that principal to this case. I only propose
> this relaxation for when a constexpr function is evaluated in a
> compile-time context.
>

--

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

<div dir=3D"ltr">Sort of related:&nbsp;https://groups.google.com/a/isocpp.o=
rg/forum/?fromgroups#!searchin/std-proposals/constexpr-specified$20loop$20v=
ariable/std-proposals/vseNksuBviI/I043vaXf8LIJ<div><br></div><div>I propose=
d a constexpr-specified loop variable would logically unroll and instantiat=
e the loop sub-statement, which would work in both compile-time and run-tim=
e functions (constexpr functions or normal functions).</div><div><br><br>On=
 Saturday, December 7, 2013 5:31:43 AM UTC+1, Mark wrote:<blockquote class=
=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>I've been toying around w=
ith the relaxed constexpr rules of C++14 in an SVN build of clang. The thou=
ght occurred to me that I might be able to use the 'natural' syntax of a fo=
r loop to iterate over the contents in a std::tuple at compile-time in a co=
nstexpr function. This seems conceptually plausible, as I am now allowed to=
 loop over a range at compile-time, but as I found out on<a href=3D"http://=
stackoverflow.com/questions/20436611/possible-to-instantiate-templates-usin=
g-a-for-loop-in-a-c14-constexpr-function" target=3D"_blank" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2=
Fquestions%2F20436611%2Fpossible-to-instantiate-templates-using-a-for-loop-=
in-a-c14-constexpr-function\46sa\75D\46sntz\0751\46usg\75AFQjCNHFuOJukqfeTx=
Iem_nEJMloe6Z7Xw';return true;" onclick=3D"this.href=3D'http://www.google.c=
om/url?q\75http%3A%2F%2Fstackoverflow.com%2Fquestions%2F20436611%2Fpossible=
-to-instantiate-templates-using-a-for-loop-in-a-c14-constexpr-function\46sa=
\75D\46sntz\0751\46usg\75AFQjCNHFuOJukqfeTxIem_nEJMloe6Z7Xw';return true;">=
 Stack Overflow</a>, when speaking strict standardese, I cannot instantiate=
 a template (like std::get) with my loop variable because the variable is n=
ot constexpr, even though it is part of a constexpr function.<br></div><div=
><br></div><div><div>A simplified example:</div><div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break=
-word"><code><div><pre style=3D"margin-bottom:10px;padding:5px;font-size:14=
px;background-color:rgb(238,238,238);font-family:Consolas,Menlo,Monaco,'Luc=
ida Console','Liberation Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono=
','Courier New',monospace,serif;overflow:auto;width:auto;max-height:600px;w=
ord-wrap:normal;color:rgb(0,0,0);line-height:18px"><code style=3D"font-fami=
ly:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mo=
no','Bitstream Vera Sans Mono','Courier New',monospace,serif"><span style=
=3D"color:#008">template</span><span style=3D"color:#660">&lt;</span><span =
style=3D"color:#008">int</span><span style=3D"color:#000"> N</span><span st=
yle=3D"color:#660">&gt;</span><span style=3D"color:#000"><br></span><span s=
tyle=3D"color:#008">constexpr</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">int</span><span style=3D"color:#000"> foo</span><spa=
n style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; </span><sp=
an style=3D"color:#008">return</span><span style=3D"color:#000"> N</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">}</span><span style=3D"color:#000"><br><br></span><s=
pan style=3D"color:#008">constexpr</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">int</span><span style=3D"color:#000"> getSum</s=
pan><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbsp; </=
span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> sum =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#066">0</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">for<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span=
><span style=3D"color:#008">auto</span><span style=3D"color:#000"> i </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#066">0</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"> i </span><span style=3D"color:#660">&lt;</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#066">10</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">++</span><span style=3D"color:#000">i</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; sum </span><span sty=
le=3D"color:#660">+=3D</span><span style=3D"color:#000"> foo</span><span st=
yle=3D"color:#080">&lt;i&gt;</span><span style=3D"color:#660">();</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">//The interestin=
g part</span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"co=
lor:#660">}</span><span style=3D"color:#000"><br>&nbsp; </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> sum</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">}</span><span style=3D"color:#000"><br><br></span><span st=
yle=3D"color:#008">constexpr</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#008">auto</span><span style=3D"color:#000"> sum </span><sp=
an style=3D"color:#660">=3D</span><span style=3D"color:#000"> getSum</span>=
<span style=3D"color:#660">();</span></code></pre></div></code></div><br><b=
r><div><br></div><div>I'd like to open discussion as to whether or not it m=
akes sense to allow this.</div></div></div><div><br></div><div><br></div><d=
iv>I should also clarify, I understand that constexpr functions can be invo=
ked at runtime. I am not talking about that case; there are already cases w=
here constexpr functions fail to compile only when used for runtime invocat=
ions, I would extend that principal to this case. I only propose this relax=
ation for when a constexpr function is evaluated in a compile-time context.=
</div></div></blockquote></div></div>

<p></p>

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

------=_Part_1668_2908975.1386433835717--

.

On 12/7/13 12:31 PM, Mark wrote:
> I've been toying around with the relaxed constexpr rules of C++14 in an SVN
> build of clang. The thought occurred to me that I might be able to use the
> 'natural' syntax of a for loop to iterate over the contents in a std::tuple
> at compile-time in a constexpr function.

Currently, each name is declared once with a definite type, and looked
up exactly once per use, or once per template instantiation in the case
of names following a template argument dependent nested-name-specifier.
Resolving a new type for a local name once per loop iteration would be
quite a radical change.

The most similar proposal is called static_if, to allow a section of
source code to be interpreted either zero or one times. Static loops are
a logical next step. The idea is very controversial, and it's not clear
that such a construct is conducive to type-safe generic programming.
(The main problem is that it attempts to ignore scoping, which your idea
doesn't require.)

The for_each idiom is doable in C++14 using the limited local template
facility in polymorphic lambdas.

template< typename tuple, typename ftor, std::size_t ... index >
void tuple_for_each_impl( tuple & t, ftor f, std::integer_sequence<
std::size_t, index ... > ) {
     int q[] = { ( f( std::get< index >( t ) ), 0 ) ... };
}

template< typename tuple, typename ftor >
void tuple_for_each( tuple && t, ftor f ) {
     tuple_for_each_impl( t, std::move( f ),
         std::make_integer_sequence< std::size_t, std::tuple_size<
typename std::decay< tuple >::type >::value >()
     );
}

tuple_for_each(
     std::make_tuple( "Hello ", true, std::string( " world!" ), 1 ),
     []( auto x ) { std::cout << x; }
);

(I was not able to test this because my GCC doesn't have
make_integer_sequence and my Clang doesn't have polymorphic lambdas.)

--

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

.

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

On Sat, Dec 7, 2013 at 9:40 PM, David Krauss <potswa@gmail.com> wrote:

> On 12/7/13 12:31 PM, Mark wrote:
>
>> I've been toying around with the relaxed constexpr rules of C++14 in an
>> SVN
>> build of clang. The thought occurred to me that I might be able to use the
>> 'natural' syntax of a for loop to iterate over the contents in a
>> std::tuple
>> at compile-time in a constexpr function.
>>
>
> Currently, each name is declared once with a definite type, and looked up
> exactly once per use, or once per template instantiation in the case of
> names following a template argument dependent nested-name-specifier.
> Resolving a new type for a local name once per loop iteration would be
> quite a radical change.
>
> The most similar proposal is called static_if, to allow a section of
> source code to be interpreted either zero or one times. Static loops are a
> logical next step. The idea is very controversial, and it's not clear that
> such a construct is conducive to type-safe generic programming. (The main
> problem is that it attempts to ignore scoping, which your idea doesn't
> require.)
>
> The for_each idiom is doable in C++14 using the limited local template
> facility in polymorphic lambdas.
>
> template< typename tuple, typename ftor, std::size_t ... index >
> void tuple_for_each_impl( tuple & t, ftor f, std::integer_sequence<
> std::size_t, index ... > ) {
>     int q[] = { ( f( std::get< index >( t ) ), 0 ) ... };
> }
>
> template< typename tuple, typename ftor >
> void tuple_for_each( tuple && t, ftor f ) {
>     tuple_for_each_impl( t, std::move( f ),
>         std::make_integer_sequence< std::size_t, std::tuple_size< typename
> std::decay< tuple >::type >::value >()
>     );
> }
>
> tuple_for_each(
>     std::make_tuple( "Hello ", true, std::string( " world!" ), 1 ),
>     []( auto x ) { std::cout << x; }
> );
>
> (I was not able to test this because my GCC doesn't have
> make_integer_sequence and my Clang doesn't have polymorphic lambdas.)


With Clang 3.4rc2 + libc++, this outputs "Hello 1 world!1"

FWIW, I think the original suggestion does not fit well into the existing
language, and would significantly muddle the semantics of constexpr
evaluation. Pack expansion seems like a much better low-level model for
performing a code fragment on each of a sequence of heterogenous
expressions, and as we see above, it's already possible to package this up
with a clean, expressive syntax, with no language extensions.

--

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

--047d7b34427ab932c604ed15e8a3
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">On S=
at, Dec 7, 2013 at 9:40 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<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 class=3D"im">On 12/7/13 12:31 PM, Mark 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">
I&#39;ve been toying around with the relaxed constexpr rules of C++14 in an=
 SVN<br>
build of clang. The thought occurred to me that I might be able to use the<=
br>
&#39;natural&#39; syntax of a for loop to iterate over the contents in a st=
d::tuple<br>
at compile-time in a constexpr function.<br>
</blockquote>
<br></div>
Currently, each name is declared once with a definite type, and looked up e=
xactly once per use, or once per template instantiation in the case of name=
s following a template argument dependent nested-name-specifier. Resolving =
a new type for a local name once per loop iteration would be quite a radica=
l change.<br>

<br>
The most similar proposal is called static_if, to allow a section of source=
 code to be interpreted either zero or one times. Static loops are a logica=
l next step. The idea is very controversial, and it&#39;s not clear that su=
ch a construct is conducive to type-safe generic programming. (The main pro=
blem is that it attempts to ignore scoping, which your idea doesn&#39;t req=
uire.)<br>

<br>
The for_each idiom is doable in C++14 using the limited local template faci=
lity in polymorphic lambdas.<br>
<br>
template&lt; typename tuple, typename ftor, std::size_t ... index &gt;<br>
void tuple_for_each_impl( tuple &amp; t, ftor f, std::integer_sequence&lt; =
std::size_t, index ... &gt; ) {<br>
=A0 =A0 int q[] =3D { ( f( std::get&lt; index &gt;( t ) ), 0 ) ... };<br>
}<br>
<br>
template&lt; typename tuple, typename ftor &gt;<br>
void tuple_for_each( tuple &amp;&amp; t, ftor f ) {<br>
=A0 =A0 tuple_for_each_impl( t, std::move( f ),<br>
=A0 =A0 =A0 =A0 std::make_integer_sequence&lt; std::size_t, std::tuple_size=
&lt; typename std::decay&lt; tuple &gt;::type &gt;::value &gt;()<br>
=A0 =A0 );<br>
}<br>
<br>
tuple_for_each(<br>
=A0 =A0 std::make_tuple( &quot;Hello &quot;, true, std::string( &quot; worl=
d!&quot; ), 1 ),<br>
=A0 =A0 []( auto x ) { std::cout &lt;&lt; x; }<br>
);<br>
<br>
(I was not able to test this because my GCC doesn&#39;t have make_integer_s=
equence and my Clang doesn&#39;t have polymorphic lambdas.)</blockquote><di=
v><br></div><div>With Clang 3.4rc2 + libc++, this outputs &quot;<span style=
=3D"color:rgb(0,0,0)">Hello 1 world!1&quot;</span></div>
<div><span style=3D"color:rgb(0,0,0)"><br></span></div><div><span style=3D"=
color:rgb(0,0,0)">FWIW, I think the original suggestion does not fit well i=
nto the existing language, and would significantly muddle the semantics of =
constexpr evaluation. Pack expansion seems like a much better low-level mod=
el for performing a code fragment on each of a sequence of heterogenous exp=
ressions, and as we see above, it&#39;s already possible to package this up=
 with a clean, expressive syntax, with no language extensions.</span></div>
</div></div></div>

<p></p>

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

--047d7b34427ab932c604ed15e8a3--

.