------=_Part_2185_14921751.1366044201040
Content-Type: text/plain; charset=ISO-8859-1

Hello everyone!
Lately I've been concerned with how we access tuple elements.
The syntax 'std::get<0>(t)' seems highly unintuitive to me.
What I would really like to be able to write is 't[0]'.
For this we need constexpr function parameters. So we can define operator[]
as follows:
auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
    return std::get<i>(*this);
}
(or something similar)

I think this would help not only for tuples.
For example, it is not possible today to pass arbitrary constexpr objects
to functions because you must pass them as a template parameter.
Template parameters must be an int/char/typename or the like. I think this
really limits constexpr objects in terms of usability.

As I see it, we can only return and operate on constexpr objects, but we
can't pass them around and maintain their "constexprness".
For example here's a silly example:
void foo(constexpr int i) {
    std::array<int, i> arr;
}

What do you think?

--

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

Hello everyone!&nbsp;<div>Lately I've been concerned with how we access tup=
le elements.</div><div>The syntax 'std::get&lt;0&gt;(t)' seems highly unint=
uitive to me.<div>What I would really like to be able to write is 't[0]'.</=
div></div><div>For this we need constexpr function parameters. So we can de=
fine operator[] as follows:</div><div>auto operator[] (constexpr int i) -&g=
t; decltype(std::get&lt;i&gt;(*this)) {</div><div>&nbsp; &nbsp; return std:=
:get&lt;i&gt;(*this);</div><div>}</div><div>(or something similar)</div><di=
v><br></div><div>I think this would help not only for tuples.</div><div>For=
 example, it is not possible today to pass arbitrary constexpr objects to f=
unctions because you must pass them as a template parameter.</div><div>Temp=
late parameters must be an int/char/typename or the like. I think this real=
ly limits constexpr objects in terms of usability.</div><div><br></div><div=
>As I see it, we can only return and operate on constexpr objects, but we c=
an't pass them around and maintain their "constexprness".</div><div>For exa=
mple here's a silly example:</div><div>void foo(constexpr int i) {</div><di=
v>&nbsp; &nbsp; std::array&lt;int, i&gt; arr;</div><div>}</div><div><br></d=
iv><div>What do you think?</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_2185_14921751.1366044201040--

.

------=_Part_555_28077418.1366058270576
Content-Type: text/plain; charset=ISO-8859-1

I'm more concerned with the C++ community trying to keep adding more and
more hacky solutions to specific problems instead of just solving the
problem once and for all properly. Pushing "everything must be a library"
and then adding new workarounds to the language because the library
solution it just doesn't quite work exactly without it.

With tuples the problem is solved once and for all by adding tuple types
and pattern matching as a built-in language feature, I don't see much
reasoning not to support tuple data-types and at least some pattern
matching on tuples, there is no reason why it could be as efficient if not
more so than any library solution. If C++ had real tuple types and pattern
matching on tuples it would look something like:

auto t1 = (1,"foo",2.2f);
auto (x, y, z) = t1; // destructing pattern, binds all elements of a
3-tuple to variables x, y, z.
auto (_, y2, _) = t1; // destructing pattern, binds the second element of a
3-tuple to 'y2' and ignores the other element.

Why can't we just have this and be done with it, it boggles the mind that
the community keeps pushing for solving particular quirky issues instead of
attacking it from the more the general case and trying to find a way to
make it work (where it has been done a number of times in other statically
typed languages very well).

Same goes with adding more and more stuff to generalized constant
expressions just to make them work in specific cases, the problem would be
(mostly) solved once and for all with a real AST-based macro system.

On Monday, April 15, 2013 5:43:21 PM UTC+1, talz...@gmail.com wrote:
>
> Hello everyone!
> Lately I've been concerned with how we access tuple elements.
> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
> What I would really like to be able to write is 't[0]'.
> For this we need constexpr function parameters. So we can define
> operator[] as follows:
> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>     return std::get<i>(*this);
> }
> (or something similar)
>
> I think this would help not only for tuples.
> For example, it is not possible today to pass arbitrary constexpr objects
> to functions because you must pass them as a template parameter.
> Template parameters must be an int/char/typename or the like. I think this
> really limits constexpr objects in terms of usability.
>
> As I see it, we can only return and operate on constexpr objects, but we
> can't pass them around and maintain their "constexprness".
> For example here's a silly example:
> void foo(constexpr int i) {
>     std::array<int, i> arr;
> }
>
> What do you think?
>

--

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

I'm more concerned with the C++ community trying to keep adding more and mo=
re hacky solutions to specific problems instead of just solving the problem=
 once and for all properly. Pushing "everything must be a library" and then=
 adding new workarounds to the language because the library solution it jus=
t doesn't quite work exactly without it.<br><br>With tuples the problem is =
solved once and for all by adding tuple types and pattern matching as a bui=
lt-in language feature, I don't see much reasoning not to support tuple dat=
a-types and at least some pattern matching on tuples, there is no reason wh=
y it could be as efficient if not more so than any library solution. If C++=
 had real tuple types and pattern matching on tuples it would look somethin=
g like:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t1=
 </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 st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"foo"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">2.2f</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> t1</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// destructing pattern, binds all elements of a 3-t=
uple to variables x, y, z.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">_</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> y2</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> _</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t1</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: #800;" class=3D"styled-by-prettify">// destructing pattern, binds t=
he second element of a 3-tuple to 'y2' and ignores the other element.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div=
></code></div><br>Why can't we just have this and be done with it, it boggl=
es the mind that the community keeps pushing for solving particular quirky =
issues instead of attacking it from the more the general case and trying to=
 find a way to make it work (where it has been done a number of times in ot=
her statically typed languages very well).<br><br>Same goes with adding mor=
e and more stuff to generalized constant expressions just to make them work=
 in specific cases, the problem would be (mostly) solved once and for all w=
ith a real AST-based macro system.<br><br>On Monday, April 15, 2013 5:43:21=
 PM UTC+1, talz...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Hello everyone!&nbsp;<div>Lately I've been concerned with how we acce=
ss tuple elements.</div><div>The syntax 'std::get&lt;0&gt;(t)' seems highly=
 unintuitive to me.<div>What I would really like to be able to write is 't[=
0]'.</div></div><div>For this we need constexpr function parameters. So we =
can define operator[] as follows:</div><div>auto operator[] (constexpr int =
i) -&gt; decltype(std::get&lt;i&gt;(*this)) {</div><div>&nbsp; &nbsp; retur=
n std::get&lt;i&gt;(*this);</div><div>}</div><div>(or something similar)</d=
iv><div><br></div><div>I think this would help not only for tuples.</div><d=
iv>For example, it is not possible today to pass arbitrary constexpr object=
s to functions because you must pass them as a template parameter.</div><di=
v>Template parameters must be an int/char/typename or the like. I think thi=
s really limits constexpr objects in terms of usability.</div><div><br></di=
v><div>As I see it, we can only return and operate on constexpr objects, bu=
t we can't pass them around and maintain their "constexprness".</div><div>F=
or example here's a silly example:</div><div>void foo(constexpr int i) {</d=
iv><div>&nbsp; &nbsp; std::array&lt;int, i&gt; arr;</div><div>}</div><div><=
br></div><div>What do you think?</div></blockquote>

<p></p>

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

------=_Part_555_28077418.1366058270576--

.

------=_Part_1099_6812746.1366072101870
Content-Type: text/plain; charset=ISO-8859-1

On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>
> Hello everyone!
> Lately I've been concerned with how we access tuple elements.
> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
> What I would really like to be able to write is 't[0]'.
> For this we need constexpr function parameters. So we can define
> operator[] as follows:
> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>     return std::get<i>(*this);
> }
> (or something similar)
>

> I think this would help not only for tuples.
> For example, it is not possible today to pass arbitrary constexpr objects
> to functions because you must pass them as a template parameter.
>

Nonsense. You can pass constexpr objects to constexpr functions just fine.
There is no *requirement* that they will be evaluated at compile-time, but
that's true of any constexpr expression that doesn't absolutely need to be
compile-time evaluated.


>  Template parameters must be an int/char/typename or the like. I think
> this really limits constexpr objects in terms of usability.
>

> As I see it, we can only return and operate on constexpr objects, but we
> can't pass them around and maintain their "constexprness".
> For example here's a silly example:
> void foo(constexpr int i) {
>     std::array<int, i> arr;
> }
>
> What do you think?
>

--

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

On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">Hello everyone!&nbsp;<div>Lately I've=
 been concerned with how we access tuple elements.</div><div>The syntax 'st=
d::get&lt;0&gt;(t)' seems highly unintuitive to me.<div>What I would really=
 like to be able to write is 't[0]'.</div></div><div>For this we need const=
expr function parameters. So we can define operator[] as follows:</div><div=
>auto operator[] (constexpr int i) -&gt; decltype(std::get&lt;i&gt;(*this))=
 {</div><div>&nbsp; &nbsp; return std::get&lt;i&gt;(*this);</div><div>}</di=
v><div>(or something similar)</div></blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div><br></div><div>I think this would help not only for =
tuples.</div><div>For example, it is not possible today to pass arbitrary c=
onstexpr objects to functions because you must pass them as a template para=
meter.</div></blockquote><div><br>Nonsense. You can pass constexpr objects =
to constexpr functions just fine. There is no <i>requirement</i> that they =
will be evaluated at compile-time, but that's true of any constexpr express=
ion that doesn't absolutely need to be compile-time evaluated.<br>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>&nbsp;Template paramet=
ers must be an int/char/typename or the like. I think this really limits co=
nstexpr objects in terms of usability.</div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div><br></div><div>As I see it, we can only re=
turn and operate on constexpr objects, but we can't pass them around and ma=
intain their "constexprness".</div><div>For example here's a silly example:=
</div><div>void foo(constexpr int i) {</div><div>&nbsp; &nbsp; std::array&l=
t;int, i&gt; arr;</div><div>}</div><div><br></div><div>What do you think?</=
div></blockquote>

<p></p>

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

------=_Part_1099_6812746.1366072101870--

.

------=_Part_2514_9068000.1366072666989
Content-Type: text/plain; charset=ISO-8859-1

You are missing the point.
This has nothing to do with constexpr functions.
What I'm proposing is to be able to pass constexpr objects with no regard
as to the function being constexpr.
In other words but I'm proposing is for the following syntax:

void foo(constexpr int i) {}

to be indentical to:

template <int i>
void foo() {}

The difference is that the constexpr version is easier to understand and
that it allows you
to pass arbitrary constexpr object types instead of just some types.

On Tuesday, April 16, 2013 3:28:21 AM UTC+3, Nicol Bolas wrote:
>
> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>
>> Hello everyone!
>> Lately I've been concerned with how we access tuple elements.
>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>> What I would really like to be able to write is 't[0]'.
>> For this we need constexpr function parameters. So we can define
>> operator[] as follows:
>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>     return std::get<i>(*this);
>> }
>> (or something similar)
>>
>
>> I think this would help not only for tuples.
>> For example, it is not possible today to pass arbitrary constexpr objects
>> to functions because you must pass them as a template parameter.
>>
>
> Nonsense. You can pass constexpr objects to constexpr functions just fine.
> There is no *requirement* that they will be evaluated at compile-time,
> but that's true of any constexpr expression that doesn't absolutely need to
> be compile-time evaluated.
>
>
>>  Template parameters must be an int/char/typename or the like. I think
>> this really limits constexpr objects in terms of usability.
>>
>
>> As I see it, we can only return and operate on constexpr objects, but we
>> can't pass them around and maintain their "constexprness".
>> For example here's a silly example:
>> void foo(constexpr int i) {
>>     std::array<int, i> arr;
>> }
>>
>> What do you think?
>>
>

--

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

You are missing the point.<div>This has nothing to do with constexpr functi=
ons.</div><div>What I'm proposing is to be able to pass constexpr objects w=
ith no regard as to the function being constexpr.</div><div>In other words =
but I'm proposing is for the following syntax:</div><div><br></div><div>voi=
d foo(constexpr int i) {}</div><div><br></div><div>to be indentical to:</di=
v><div><br></div><div>template &lt;int i&gt;</div><div>void foo() {}</div><=
div><br></div><div>The difference is that the constexpr version is easier t=
o understand and that it allows you</div><div>to pass arbitrary constexpr o=
bject types instead of just some types.</div><div><br>On Tuesday, April 16,=
 2013 3:28:21 AM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">On Monday, April 15, 2013 9:43:21 AM UTC-7, <a>talz...@gmail.co=
m</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone!&nbsp;<d=
iv>Lately I've been concerned with how we access tuple elements.</div><div>=
The syntax 'std::get&lt;0&gt;(t)' seems highly unintuitive to me.<div>What =
I would really like to be able to write is 't[0]'.</div></div><div>For this=
 we need constexpr function parameters. So we can define operator[] as foll=
ows:</div><div>auto operator[] (constexpr int i) -&gt; decltype(std::get&lt=
;i&gt;(*this)) {</div><div>&nbsp; &nbsp; return std::get&lt;i&gt;(*this);</=
div><div>}</div><div>(or something similar)</div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div><br></div><div>I think this would help not =
only for tuples.</div><div>For example, it is not possible today to pass ar=
bitrary constexpr objects to functions because you must pass them as a temp=
late parameter.</div></blockquote><div><br>Nonsense. You can pass constexpr=
 objects to constexpr functions just fine. There is no <i>requirement</i> t=
hat they will be evaluated at compile-time, but that's true of any constexp=
r expression that doesn't absolutely need to be compile-time evaluated.<br>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>&nbsp;Template par=
ameters must be an int/char/typename or the like. I think this really limit=
s constexpr objects in terms of usability.</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div><br></div><div>As I see it, we can only retu=
rn and operate on constexpr objects, but we can't pass them around and main=
tain their "constexprness".</div><div>For example here's a silly example:</=
div><div>void foo(constexpr int i) {</div><div>&nbsp; &nbsp; std::array&lt;=
int, i&gt; arr;</div><div>}</div><div><br></div><div>What do you think?</di=
v></blockquote></blockquote></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_2514_9068000.1366072666989--

.

------=_Part_4903_18660498.1366087314410
Content-Type: text/plain; charset=ISO-8859-1

On Monday, April 15, 2013 5:37:46 PM UTC-7, talz...@gmail.com wrote:
>
> You are missing the point.
> This has nothing to do with constexpr functions.
> What I'm proposing is to be able to pass constexpr objects with no regard
> as to the function being constexpr.
> In other words but I'm proposing is for the following syntax:
>
> void foo(constexpr int i) {}
>
> to be indentical to:
>
> template <int i>
> void foo() {}
>
> The difference is that the constexpr version is easier to understand and
> that it allows you
> to pass arbitrary constexpr object types instead of just some types.
>

There are reasons why templates don't allow arbitrary objects as template
parameters. Among other things, template instantiation requires code
generation. And code generation is contingent on what you instantiate a
template with. `foo<5>` is a different function from `foo<4>`. If you
instantiate a template with the same parameters in two places, you should
get the same function generated. Allowing arbitrary objects as templates
makes it very difficult to know what "the same parameters" even means.

In short, it's a bad idea. Just because you changed the syntax around it
doesn't mean that it isn't still a bad idea. Template parameters are
different things from function arguments, and they should not be treated
the same way.

Furthermore, there's no reason why a function's arguments should ever be
prevented from taking values that *aren't* compile-time constants. What
would you use it for? Why would you want to *prevent* someone from calling
`foo(integerValue)`?

--

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

On Monday, April 15, 2013 5:37:46 PM UTC-7, talz...@gmail.com wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">You are missing the point.<div>This h=
as nothing to do with constexpr functions.</div><div>What I'm proposing is =
to be able to pass constexpr objects with no regard as to the function bein=
g constexpr.</div><div>In other words but I'm proposing is for the followin=
g syntax:</div><div><br></div><div>void foo(constexpr int i) {}</div><div><=
br></div><div>to be indentical to:</div><div><br></div><div>template &lt;in=
t i&gt;</div><div>void foo() {}</div><div><br></div><div>The difference is =
that the constexpr version is easier to understand and that it allows you</=
div><div>to pass arbitrary constexpr object types instead of just some type=
s.</div></blockquote><div><br>There are reasons why templates don't allow a=
rbitrary objects as template parameters. Among other things, template insta=
ntiation requires code generation. And code generation is contingent on wha=
t you instantiate a template with. `foo&lt;5&gt;` is a different function f=
rom `foo&lt;4&gt;`. If you instantiate a template with the same parameters =
in two places, you should get the same function generated. Allowing arbitra=
ry objects as templates makes it very difficult to know what "the same para=
meters" even means.<br><br>In short, it's a bad idea. Just because you chan=
ged the syntax around it doesn't mean that it isn't still a bad idea. Templ=
ate parameters are different things from function arguments, and they shoul=
d not be treated the same way.<br><br>Furthermore, there's no reason why a =
function's arguments should ever be prevented from taking values that <i>ar=
en't</i> compile-time constants. What would you use it for? Why would you w=
ant to <i>prevent</i> someone from calling `foo(integerValue)`?</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 />

------=_Part_4903_18660498.1366087314410--

.

Just to point out something related:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.html

16.4.2013 6:41, Nicol Bolas kirjoitti:
> On Monday, April 15, 2013 5:37:46 PM UTC-7, talz...@gmail.com wrote:
>
>     You are missing the point.
>     This has nothing to do with constexpr functions.
>     What I'm proposing is to be able to pass constexpr objects with no
>     regard as to the function being constexpr.
>     In other words but I'm proposing is for the following syntax:
>
>     void foo(constexpr int i) {}
>
>     to be indentical to:
>
>     template <int i>
>     void foo() {}
>
>     The difference is that the constexpr version is easier to
>     understand and that it allows you
>     to pass arbitrary constexpr object types instead of just some types.
>
>
> There are reasons why templates don't allow arbitrary objects as
> template parameters. Among other things, template instantiation
> requires code generation. And code generation is contingent on what
> you instantiate a template with. `foo<5>` is a different function from
> `foo<4>`. If you instantiate a template with the same parameters in
> two places, you should get the same function generated. Allowing
> arbitrary objects as templates makes it very difficult to know what
> "the same parameters" even means.
>
> In short, it's a bad idea. Just because you changed the syntax around
> it doesn't mean that it isn't still a bad idea. Template parameters
> are different things from function arguments, and they should not be
> treated the same way.
>
> Furthermore, there's no reason why a function's arguments should ever
> be prevented from taking values that /aren't/ compile-time constants.
> What would you use it for? Why would you want to /prevent/ someone
> from calling `foo(integerValue)`?
>
> --
>
> ---
> 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_2152_79128.1366107696841
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you! I didn't notice that proposal. I'm all for it =3D)
Maybe then we could stop having things like ratio<3,4> and be able to pass=
=20
normal constexpr objects in template specifications.

On Tuesday, April 16, 2013 12:46:19 PM UTC+3, Mikael Kilpel=E4inen wrote:
>
> Just to point out something related:=20
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.html=20
>
> 16.4.2013 6:41, Nicol Bolas kirjoitti:=20
> > On Monday, April 15, 2013 5:37:46 PM UTC-7, talz...@gmail.com wrote:=20
> >=20
> >     You are missing the point.=20
> >     This has nothing to do with constexpr functions.=20
> >     What I'm proposing is to be able to pass constexpr objects with no=
=20
> >     regard as to the function being constexpr.=20
> >     In other words but I'm proposing is for the following syntax:=20
> >=20
> >     void foo(constexpr int i) {}=20
> >=20
> >     to be indentical to:=20
> >=20
> >     template <int i>=20
> >     void foo() {}=20
> >=20
> >     The difference is that the constexpr version is easier to=20
> >     understand and that it allows you=20
> >     to pass arbitrary constexpr object types instead of just some types=
..=20
> >=20
> >=20
> > There are reasons why templates don't allow arbitrary objects as=20
> > template parameters. Among other things, template instantiation=20
> > requires code generation. And code generation is contingent on what=20
> > you instantiate a template with. `foo<5>` is a different function from=
=20
> > `foo<4>`. If you instantiate a template with the same parameters in=20
> > two places, you should get the same function generated. Allowing=20
> > arbitrary objects as templates makes it very difficult to know what=20
> > "the same parameters" even means.=20
> >=20
> > In short, it's a bad idea. Just because you changed the syntax around=
=20
> > it doesn't mean that it isn't still a bad idea. Template parameters=20
> > are different things from function arguments, and they should not be=20
> > treated the same way.=20
> >=20
> > Furthermore, there's no reason why a function's arguments should ever=
=20
> > be prevented from taking values that /aren't/ compile-time constants.=
=20
> > What would you use it for? Why would you want to /prevent/ someone=20
> > from calling `foo(integerValue)`?=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> > Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> > an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.=20
> >=20
> >=20
>
>

--=20

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



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

Thank you! I didn't notice that proposal. I'm all for it =3D)<div>Maybe the=
n we could stop having things like ratio&lt;3,4&gt; and be able to pass nor=
mal constexpr objects in template specifications.</div><div><br>On Tuesday,=
 April 16, 2013 12:46:19 PM UTC+3, Mikael Kilpel=E4inen wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">Just to point out something related:
<br>
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3413.ht=
ml" target=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2=
012/n3413.<wbr>html</a>
<br>
<br>16.4.2013 6:41, Nicol Bolas kirjoitti:
<br>&gt; On Monday, April 15, 2013 5:37:46 PM UTC-7, <a>talz...@gmail.com</=
a> wrote:
<br>&gt;
<br>&gt; &nbsp; &nbsp; You are missing the point.
<br>&gt; &nbsp; &nbsp; This has nothing to do with constexpr functions.
<br>&gt; &nbsp; &nbsp; What I'm proposing is to be able to pass constexpr o=
bjects with no
<br>&gt; &nbsp; &nbsp; regard as to the function being constexpr.
<br>&gt; &nbsp; &nbsp; In other words but I'm proposing is for the followin=
g syntax:
<br>&gt;
<br>&gt; &nbsp; &nbsp; void foo(constexpr int i) {}
<br>&gt;
<br>&gt; &nbsp; &nbsp; to be indentical to:
<br>&gt;
<br>&gt; &nbsp; &nbsp; template &lt;int i&gt;
<br>&gt; &nbsp; &nbsp; void foo() {}
<br>&gt;
<br>&gt; &nbsp; &nbsp; The difference is that the constexpr version is easi=
er to
<br>&gt; &nbsp; &nbsp; understand and that it allows you
<br>&gt; &nbsp; &nbsp; to pass arbitrary constexpr object types instead of =
just some types.
<br>&gt;
<br>&gt;
<br>&gt; There are reasons why templates don't allow arbitrary objects as=
=20
<br>&gt; template parameters. Among other things, template instantiation=20
<br>&gt; requires code generation. And code generation is contingent on wha=
t=20
<br>&gt; you instantiate a template with. `foo&lt;5&gt;` is a different fun=
ction from=20
<br>&gt; `foo&lt;4&gt;`. If you instantiate a template with the same parame=
ters in=20
<br>&gt; two places, you should get the same function generated. Allowing=
=20
<br>&gt; arbitrary objects as templates makes it very difficult to know wha=
t=20
<br>&gt; "the same parameters" even means.
<br>&gt;
<br>&gt; In short, it's a bad idea. Just because you changed the syntax aro=
und=20
<br>&gt; it doesn't mean that it isn't still a bad idea. Template parameter=
s=20
<br>&gt; are different things from function arguments, and they should not =
be=20
<br>&gt; treated the same way.
<br>&gt;
<br>&gt; Furthermore, there's no reason why a function's arguments should e=
ver=20
<br>&gt; be prevented from taking values that /aren't/ compile-time constan=
ts.=20
<br>&gt; What would you use it for? Why would you want to /prevent/ someone=
=20
<br>&gt; from calling `foo(integerValue)`?
<br>&gt;
<br>&gt; --=20
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
=20
<br>&gt; Groups "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send=20
<br>&gt; an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"K6pdRNNv8CoJ">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"K6pdRNNv8CoJ">std-pr...@isocpp.org</a=
>.
<br>&gt; Visit this group at=20
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/g=
roup/std-<wbr>proposals/?hl=3Den</a>.
<br>&gt;
<br>&gt;
<br>
<br></blockquote></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_2152_79128.1366107696841--

.

I'd actually like to see this as a form of template argument deduction.
For example:

template <int i>
int operator [](constexpr int i) {
    // Same i as function parameter and template parameter.
    return i;
}

This is especially useful when you want to return a result of a
different type based on the value, for example when taking the exponent
of an MKS quantity:

template <int M, int K, int S>
class Quantity {
    // Represents exponents
    template <int i>
    // Deduce template argument based on function argument.
    Quantity<M * i, K * i, S * i> operator [](constexpr int i) {
        return Quantity<M * i, K * i, S * i>(std::pow(this->value, i));
    }
};

Matching names may not be the way to go, though... maybe some other syntax
that binds a template parameter to a function parameter, like
'constexpr int j -> i', or something like that.  Then you can have both
beautiful and type-rich code for stuff like
'Force f = 12.5_kg*m/s[2]', where _kg is a user-defined literal suffix,
and m and s are constants.

--

---
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_362_24295255.1397841763391
Content-Type: text/plain; charset=UTF-8

On Monday, April 15, 2013 9:41:54 PM UTC-7, Nicol Bolas wrote:
>
>
> Furthermore, there's no reason why a function's arguments should ever be
> prevented from taking values that *aren't* compile-time constants. What
> would you use it for? Why would you want to *prevent* someone from
> calling `foo(integerValue)`?
>

Assuming that overloading is part of the bargain:

There's cases where you might want to select algorithms or implementations
based on whether a compiler is doing the work or a CPU is doing the work.
You can't use CPU intrinsics in constexpr functions, for instance
(especially in cross-compiles and the like), but a hand-optimized SSE
version of some operation can be a significant runtime enhancement over the
constexpr-friendly version (especially in debug builds; it's nice to have a
playable game in debug-mode and not just a pretty slideshow). The same can
go for hash functions. It could also be handy to overload based on string
literals (right now you can't tell a string literal apart from any random
character buffer) for certain kinds of string-based interfaces (if nothing
else it lets you determine at compile time if you need a copy of a string
or can just use its address), which constexpr arguments at least makes a
bit easier if not fool-proof. You can now just name them separately and
with some clear convention, but that needlessly complicates template logic
and functional interface design.

--

---
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_362_24295255.1397841763391
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, April 15, 2013 9:41:54 PM UTC-7, Nicol Bolas wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>Furthermore, ther=
e's no reason why a function's arguments should ever be prevented from taki=
ng values that <i>aren't</i> compile-time constants. What would you use it =
for? Why would you want to <i>prevent</i> someone from calling `foo(integer=
Value)`?</div></blockquote><div><br></div><div>Assuming that overloading is=
 part of the bargain:<br></div><div><br></div><div>There's cases where you =
might want to select algorithms or implementations based on whether a compi=
ler is doing the work or a CPU is doing the work. You can't use CPU intrins=
ics in constexpr functions, for instance (especially in cross-compiles and =
the like), but a hand-optimized SSE version of some operation can be a sign=
ificant runtime enhancement over the constexpr-friendly version (especially=
 in debug builds; it's nice to have a playable game in debug-mode and not j=
ust a pretty slideshow). The same can go for hash functions. It could also =
be handy to overload based on string literals (right now you can't tell a s=
tring literal apart from any random character buffer) for certain kinds of =
string-based interfaces (if nothing else it lets you determine at compile t=
ime if you need a copy of a string or can just use its address), which cons=
texpr arguments at least makes a bit easier if not fool-proof. You can now =
just name them separately and with some clear convention, but that needless=
ly complicates template logic and functional interface design.</div></div>

<p></p>

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

------=_Part_362_24295255.1397841763391--

.

------=_Part_1030_4339335.1398503300292
Content-Type: text/plain; charset=UTF-8


>
> Lately I've been concerned with how we access tuple elements.
> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
> What I would really like to be able to write is 't[0]'.
>

It can be achieved using C++11 user-defined literals:

#include <iostream>
#include <tuple>
#include <type_traits>
#include <string>

template <size_t i>
using Index = std::integral_constant<size_t, i>;

template <class... Types>
struct Tuple : std::tuple<Types...>
{
    using std::tuple<Types...>::tuple;

    template <size_t i>
    auto operator [] (const Index<i>&) -> decltype(std::get<i>(*this))
    {
        return std::get<i>(*this);
    }

    template <size_t i>
    auto operator [] (const Index<i>&) const -> decltype(std::get<i>(*this))
    {
        return std::get<i>(*this);
    }
};

template <size_t N, char... Digits>
struct Number_ : std::integral_constant<size_t, N> {};

template <size_t N, char Digit, char... Digits>
struct Number_<N, Digit, Digits...> :
    std::integral_constant<size_t, Number_<N * 10 + (Digit - '0'),
Digits...>::value>
{
    static_assert(('0' <= Digit) && (Digit <= '9'), "Invalid digit in index
string");
};

template <char... Digits>
struct Number : Number_<0, Digits...> {};

template <char... Digits>
constexpr Index<Number<Digits...>::value> operator "" _i() noexcept
{
    return {};
}

int main() {
    int i = 42;
    double f = 3.14;
    std::string s = "Hello, world!";
    Tuple<int, double, std::string> t(i, f, s);

    std::cout << t[0_i] << std::endl;
    std::cout << t[1_i] << std::endl;
    std::cout << t[2_i] << std::endl;
}

See live example <http://coliru.stacked-crooked.com/a/b9b2b304ed280c63>.

Another way is to use C++14 variable templates:

// ...

template <size_t i>
constexpr Index<i> I{};

// ...

std::cout << t[I<0>] << std::endl;
std::cout << t[I<1>] << std::endl;
std::cout << t[I<2>] << std::endl;

// ...

See live example <http://coliru.stacked-crooked.com/a/50f16bdbb8bab112>.

--

---
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_1030_4339335.1398503300292
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Lately I=
've been concerned with how we access tuple elements.</div><div>The syntax =
'std::get&lt;0&gt;(t)' seems highly unintuitive to me.<div>What I would rea=
lly like to be able to write is 't[0]'.</div></div></blockquote><div><br></=
div><div>It can be achieved using C++11 user-defined literals:</div><div><b=
r></div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#66=
6600"><div class=3D"subprettyprint">#include &lt;iostream&gt;</div><div cla=
ss=3D"subprettyprint">#include &lt;tuple&gt;</div><div class=3D"subprettypr=
int">#include &lt;type_traits&gt;</div><div class=3D"subprettyprint">#inclu=
de &lt;string&gt;</div><div class=3D"subprettyprint"><br></div><div class=
=3D"subprettyprint">template &lt;size_t i&gt;</div><div class=3D"subprettyp=
rint">using Index =3D std::integral_constant&lt;size_t, i&gt;;</div><div cl=
ass=3D"subprettyprint"><br></div><div class=3D"subprettyprint">template &lt=
;class... Types&gt;</div><div class=3D"subprettyprint">struct Tuple : std::=
tuple&lt;Types...&gt;</div><div class=3D"subprettyprint">{</div><div class=
=3D"subprettyprint">&nbsp; &nbsp; using std::tuple&lt;Types...&gt;::tuple;<=
/div><div class=3D"subprettyprint">&nbsp; &nbsp;&nbsp;</div><div class=3D"s=
ubprettyprint">&nbsp; &nbsp; template &lt;size_t i&gt;</div><div class=3D"s=
ubprettyprint">&nbsp; &nbsp; auto operator [] (const Index&lt;i&gt;&amp;) -=
&gt; decltype(std::get&lt;i&gt;(*this))</div><div class=3D"subprettyprint">=
&nbsp; &nbsp; {</div><div class=3D"subprettyprint">&nbsp; &nbsp; &nbsp; &nb=
sp; return std::get&lt;i&gt;(*this);</div><div class=3D"subprettyprint">&nb=
sp; &nbsp; }</div><div class=3D"subprettyprint">&nbsp; &nbsp;&nbsp;</div><d=
iv class=3D"subprettyprint">&nbsp; &nbsp; template &lt;size_t i&gt;</div><d=
iv class=3D"subprettyprint">&nbsp; &nbsp; auto operator [] (const Index&lt;=
i&gt;&amp;) const -&gt; decltype(std::get&lt;i&gt;(*this))</div><div class=
=3D"subprettyprint">&nbsp; &nbsp; {</div><div class=3D"subprettyprint">&nbs=
p; &nbsp; &nbsp; &nbsp; return std::get&lt;i&gt;(*this);</div><div class=3D=
"subprettyprint">&nbsp; &nbsp; }</div><div class=3D"subprettyprint">};</div=
><div class=3D"subprettyprint"><br></div><div class=3D"subprettyprint">temp=
late &lt;size_t N, char... Digits&gt;</div><div class=3D"subprettyprint">st=
ruct Number_ : std::integral_constant&lt;size_t, N&gt; {};</div><div class=
=3D"subprettyprint"><br></div><div class=3D"subprettyprint">template &lt;si=
ze_t N, char Digit, char... Digits&gt;</div><div class=3D"subprettyprint">s=
truct Number_&lt;N, Digit, Digits...&gt; :</div><div class=3D"subprettyprin=
t">&nbsp; &nbsp; std::integral_constant&lt;size_t, Number_&lt;N * 10 + (Dig=
it - '0'), Digits...&gt;::value&gt;</div><div class=3D"subprettyprint">{</d=
iv><div class=3D"subprettyprint">&nbsp; &nbsp; static_assert(('0' &lt;=3D D=
igit) &amp;&amp; (Digit &lt;=3D '9'), "Invalid digit in index string");</di=
v><div class=3D"subprettyprint">};</div><div class=3D"subprettyprint"><br><=
/div><div class=3D"subprettyprint">template &lt;char... Digits&gt;</div><di=
v class=3D"subprettyprint">struct Number : Number_&lt;0, Digits...&gt; {};<=
/div><div class=3D"subprettyprint"><br></div><div class=3D"subprettyprint">=
template &lt;char... Digits&gt;</div><div class=3D"subprettyprint">constexp=
r Index&lt;Number&lt;Digits...&gt;::value&gt; operator "" _i() noexcept</di=
v><div class=3D"subprettyprint">{</div><div class=3D"subprettyprint">&nbsp;=
 &nbsp; return {};</div><div class=3D"subprettyprint">}</div><div class=3D"=
subprettyprint"><br></div><div class=3D"subprettyprint">int main() {</div><=
div class=3D"subprettyprint">&nbsp; &nbsp; int i =3D 42;</div><div class=3D=
"subprettyprint">&nbsp; &nbsp; double f =3D 3.14;</div><div class=3D"subpre=
ttyprint">&nbsp; &nbsp; std::string s =3D "Hello, world!";</div><div class=
=3D"subprettyprint">&nbsp; &nbsp; Tuple&lt;int, double, std::string&gt; t(i=
, f, s);</div><div class=3D"subprettyprint">&nbsp; &nbsp;&nbsp;</div><div c=
lass=3D"subprettyprint">&nbsp; &nbsp; std::cout &lt;&lt; t[0_i] &lt;&lt; st=
d::endl;</div><div class=3D"subprettyprint">&nbsp; &nbsp; std::cout &lt;&lt=
; t[1_i] &lt;&lt; std::endl;</div><div class=3D"subprettyprint">&nbsp; &nbs=
p; std::cout &lt;&lt; t[2_i] &lt;&lt; std::endl;</div><div class=3D"subpret=
typrint">}</div></font></div></code></div><br>See <a href=3D"http://coliru.=
stacked-crooked.com/a/b9b2b304ed280c63">live example</a>.</div><div><br></d=
iv><div>Another way is to use C++14 variable templates:</div><div><br></div=
><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#666600"><=
div class=3D"subprettyprint">// ...<br><br>template &lt;size_t i&gt;</div><=
div class=3D"subprettyprint">constexpr Index&lt;i&gt; I{};</div><div class=
=3D"subprettyprint"><br></div><div class=3D"subprettyprint">// ...<br><span=
 style=3D"font-family: Arial, Helvetica, sans-serif;"> &nbsp; &nbsp;</span>=
<br></div><div class=3D"subprettyprint">std::cout &lt;&lt; t[I&lt;0&gt;] &l=
t;&lt; std::endl;</div><div class=3D"subprettyprint">std::cout &lt;&lt; t[I=
&lt;1&gt;] &lt;&lt; std::endl;</div><div class=3D"subprettyprint">std::cout=
 &lt;&lt; t[I&lt;2&gt;] &lt;&lt; std::endl;<br><br>// ...</div></font></div=
></code></div><br></div><div>See <a href=3D"http://coliru.stacked-crooked.c=
om/a/50f16bdbb8bab112">live example</a>.</div></div>

<p></p>

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

------=_Part_1030_4339335.1398503300292--

.

------=_Part_760_28444315.1398558043204
Content-Type: text/plain; charset=UTF-8

On Saturday, April 26, 2014 2:08:20 AM UTC-7, Constructor wrote:
>
> Lately I've been concerned with how we access tuple elements.
>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>> What I would really like to be able to write is 't[0]'.
>>
>
> It can be achieved using C++11 user-defined literals:
>

Some feedback I got on N3761 was that this exact feature was something
they'd like to explore instead of a library solution. I've been meaning to
write a follow-up paper but am unlikely to get to it anytime soon.

--

---
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_760_28444315.1398558043204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, April 26, 2014 2:08:20 AM UTC-7, Constructor =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div>Lately I've been concerned with how w=
e access tuple elements.</div><div>The syntax 'std::get&lt;0&gt;(t)' seems =
highly unintuitive to me.<div>What I would really like to be able to write =
is 't[0]'.</div></div></blockquote><div><br></div><div>It can be achieved u=
sing C++11 user-defined literals:</div></div></blockquote><div><br></div><d=
iv>Some feedback I got on N3761 was that this exact feature was something t=
hey'd like to explore instead of a library solution. I've been meaning to w=
rite a follow-up paper but am unlikely to get to it anytime soon.</div></di=
v>

<p></p>

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

------=_Part_760_28444315.1398558043204--

.

------=_Part_1024_6881824.1398502801695
Content-Type: text/plain; charset=UTF-8


>
> Lately I've been concerned with how we access tuple elements.
> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
> What I would really like to be able to write is 't[0]'.
>
 It can be achieved using standard C++11 feature. I mean user-defined
literals:

#include <iostream>
#include <tuple>
#include <type_traits>
#include <string>

template <size_t i>
using Index = std::integral_constant<size_t, i>;

template <class... Types>
struct Tuple : std::tuple<Types...>
{
    using std::tuple<Types...>::tuple;

    template <size_t i>
    auto operator [] (const Index<i>&) -> decltype(std::get<i>(*this))
    {
        return std::get<i>(*this);
    }

    template <size_t i>
    auto operator [] (const Index<i>&) const -> decltype(std::get<i>(*this))
    {
        return std::get<i>(*this);
    }
};

template <size_t N, char... Digits>
struct Number_ : std::integral_constant<size_t, N> {};

template <size_t N, char Digit, char... Digits>
struct Number_<N, Digit, Digits...> :
    std::integral_constant<size_t, Number_<N * 10 + (Digit - '0'),
Digits...>::value>
{
    static_assert(('0' <= Digit) && (Digit <= '9'), "Invalid digit in index
string");
};

template <char... Digits>
struct Number : Number_<0, Digits...> {};

template <char... Digits>
constexpr Index<Number<Digits...>::value> operator "" _i() noexcept
{
    return {};
}

int main() {
    int i = 42;
    double f = 3.14;
    std::string s = "Hello, world!";
    Tuple<int, double, std::string> t(i, f, s);

    std::cout << t[0_i] << std::endl;
    std::cout << t[1_i] << std::endl;
    std::cout << t[2_i] << std::endl;
}

See live example. <http://coliru.stacked-crooked.com/a/b9b2b304ed280c63>

Another variant is to use C++14 variable templates:

// ...

template <size_t i>
constexpr Index<i> I{};

// ...

std::cout << t[I<0>] << std::endl;
std::cout << t[I<1>] << std::endl;
std::cout << t[I<2>] << std::endl;

See live example <http://coliru.stacked-crooked.com/a/50f16bdbb8bab112>.

--

---
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_1024_6881824.1398502801695
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Lately I=
've been concerned with how we access tuple elements.</div><div>The syntax =
'std::get&lt;0&gt;(t)' seems highly unintuitive to me.<div>What I would rea=
lly like to be able to write is 't[0]'.</div></div></blockquote><div>&nbsp;=
It can be achieved using standard C++11 feature. I mean user-defined litera=
ls:</div><div><br></div><div><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><d=
iv class=3D"subprettyprint"><div class=3D"subprettyprint"><font color=3D"#8=
80000"><div class=3D"subprettyprint"><div class=3D"subprettyprint">#include=
 &lt;iostream&gt;</div><div class=3D"subprettyprint">#include &lt;tuple&gt;=
</div><div class=3D"subprettyprint">#include &lt;type_traits&gt;</div><div =
class=3D"subprettyprint">#include &lt;string&gt;</div><div class=3D"subpret=
typrint"><br></div><div class=3D"subprettyprint">template &lt;size_t i&gt;<=
/div><div class=3D"subprettyprint">using Index =3D std::integral_constant&l=
t;size_t, i&gt;;</div><div class=3D"subprettyprint"><br></div><div class=3D=
"subprettyprint">template &lt;class... Types&gt;</div><div class=3D"subpret=
typrint">struct Tuple : std::tuple&lt;Types...&gt;</div><div class=3D"subpr=
ettyprint">{</div><div class=3D"subprettyprint">&nbsp; &nbsp; using std::tu=
ple&lt;Types...&gt;::tuple;</div><div class=3D"subprettyprint">&nbsp; &nbsp=
;&nbsp;</div><div class=3D"subprettyprint">&nbsp; &nbsp; template &lt;size_=
t i&gt;</div><div class=3D"subprettyprint">&nbsp; &nbsp; auto operator [] (=
const Index&lt;i&gt;&amp;) -&gt; decltype(std::get&lt;i&gt;(*this))</div><d=
iv class=3D"subprettyprint">&nbsp; &nbsp; {</div><div class=3D"subprettypri=
nt">&nbsp; &nbsp; &nbsp; &nbsp; return std::get&lt;i&gt;(*this);</div><div =
class=3D"subprettyprint">&nbsp; &nbsp; }</div><div class=3D"subprettyprint"=
>&nbsp; &nbsp;&nbsp;</div><div class=3D"subprettyprint">&nbsp; &nbsp; templ=
ate &lt;size_t i&gt;</div><div class=3D"subprettyprint">&nbsp; &nbsp; auto =
operator [] (const Index&lt;i&gt;&amp;) const -&gt; decltype(std::get&lt;i&=
gt;(*this))</div><div class=3D"subprettyprint">&nbsp; &nbsp; {</div><div cl=
ass=3D"subprettyprint">&nbsp; &nbsp; &nbsp; &nbsp; return std::get&lt;i&gt;=
(*this);</div><div class=3D"subprettyprint">&nbsp; &nbsp; }</div><div class=
=3D"subprettyprint">};</div><div class=3D"subprettyprint"><br></div><div cl=
ass=3D"subprettyprint">template &lt;size_t N, char... Digits&gt;</div><div =
class=3D"subprettyprint">struct Number_ : std::integral_constant&lt;size_t,=
 N&gt; {};</div><div class=3D"subprettyprint"><br></div><div class=3D"subpr=
ettyprint">template &lt;size_t N, char Digit, char... Digits&gt;</div><div =
class=3D"subprettyprint">struct Number_&lt;N, Digit, Digits...&gt; :</div><=
div class=3D"subprettyprint">&nbsp; &nbsp; std::integral_constant&lt;size_t=
, Number_&lt;N * 10 + (Digit - '0'), Digits...&gt;::value&gt;</div><div cla=
ss=3D"subprettyprint">{</div><div class=3D"subprettyprint">&nbsp; &nbsp; st=
atic_assert(('0' &lt;=3D Digit) &amp;&amp; (Digit &lt;=3D '9'), "Invalid di=
git in index string");</div><div class=3D"subprettyprint">};</div><div clas=
s=3D"subprettyprint"><br></div><div class=3D"subprettyprint">template &lt;c=
har... Digits&gt;</div><div class=3D"subprettyprint">struct Number : Number=
_&lt;0, Digits...&gt; {};</div><div class=3D"subprettyprint"><br></div><div=
 class=3D"subprettyprint">template &lt;char... Digits&gt;</div><div class=
=3D"subprettyprint">constexpr Index&lt;Number&lt;Digits...&gt;::value&gt; o=
perator "" _i() noexcept</div><div class=3D"subprettyprint">{</div><div cla=
ss=3D"subprettyprint">&nbsp; &nbsp; return {};</div><div class=3D"subpretty=
print">}</div><div class=3D"subprettyprint"><br></div><div class=3D"subpret=
typrint">int main() {</div><div class=3D"subprettyprint">&nbsp; &nbsp; int =
i =3D 42;</div><div class=3D"subprettyprint">&nbsp; &nbsp; double f =3D 3.1=
4;</div><div class=3D"subprettyprint">&nbsp; &nbsp; std::string s =3D "Hell=
o, world!";</div><div class=3D"subprettyprint">&nbsp; &nbsp; Tuple&lt;int, =
double, std::string&gt; t(i, f, s);</div><div class=3D"subprettyprint">&nbs=
p; &nbsp;&nbsp;</div><div class=3D"subprettyprint">&nbsp; &nbsp; std::cout =
&lt;&lt; t[0_i] &lt;&lt; std::endl;</div><div class=3D"subprettyprint">&nbs=
p; &nbsp; std::cout &lt;&lt; t[1_i] &lt;&lt; std::endl;</div><div class=3D"=
subprettyprint">&nbsp; &nbsp; std::cout &lt;&lt; t[2_i] &lt;&lt; std::endl;=
</div><div class=3D"subprettyprint">}</div></div></font></div></div></div><=
/code></div><div><br></div><div>See l<a href=3D"http://coliru.stacked-crook=
ed.com/a/b9b2b304ed280c63">ive example.</a></div></div><div><br></div><div>=
Another variant is to use C++14 variable templates:</div><div><br></div><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint">// ...<br><br>template &lt;size_t =
i&gt;<br>constexpr Index&lt;i&gt; I{};<br><br>// ...<br><br>std::cout &lt;&=
lt; t[I&lt;0&gt;] &lt;&lt; std::endl;<br>std::cout &lt;&lt; t[I&lt;1&gt;] &=
lt;&lt; std::endl;<br>std::cout &lt;&lt; t[I&lt;2&gt;] &lt;&lt; std::endl;<=
/div></code></div><div><div><br></div></div><div>See <a href=3D"http://coli=
ru.stacked-crooked.com/a/50f16bdbb8bab112">live example</a>.</div></div>

<p></p>

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

------=_Part_1024_6881824.1398502801695--

.

------=_Part_2232_25312049.1398956411510
Content-Type: text/plain; charset=UTF-8

Actually, cleaner solution for the tuple is also possible:

#include <tuple>
#include <string>
template<typename... Types>
struct Purr {
    std::tuple<Types...> t;
    template<int i>
    auto get() -> decltype(std::get<i>(t)) { return std::get<i>(t); }
};
int main() {
    Purr<int, double, std::string> p;
    p.get<0>() = 1;
    p.get<1>() = 4.5;
    p.get<2>() = "meow";
}

Works in MSVC2013, GCC 4.9.0 and Clang 3.3: http://goo.gl/MPHhMb

(Although, I can still imagine that it's somehow non-standard, but it's
just formality after major compilers accept it :) )

A bit more for constexpr parameters: I love promoting every possible
computation to compile time, after all, noone expects to generate (release)
code that adds 2+2 at runtime for "int i = 2+2;". If the constexpr
parameters could mean to allow for generating a runtime and a
"compile-time" versions of the function, I'd be very interested. Example:

int foo(constexpr bool opt1, constexpr bool opt2) {
    if (opt1) lengtyStuff();
    moreStuff();
    if (opt2) stuffstuff();
    evenMoreStuff();
}
int main() {
    bool userChoice1 = askUser();
    bool userChoice2 = askUser();
    foo(userChoice1, userChoice2); //generates code with 2 branch
instructions
    foo(true, false); //no branch instruction, aka "foo<true, false>"
    foo(userChoice1, true); //1 branch instr, aka "foo<true>(userChoice1)"
}
(In the middle of tight loops, this can matter quite a lot.)

Regards, Robert

--

---
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_2232_25312049.1398956411510
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Actually, cleaner solution for the tuple is also possible:=
<br><br><pre style=3D"font-family:Consolas;font-size:13;color:black;backgro=
und:white;"><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code 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;" class=3D"styled-by-prettify">&lt;tuple&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">#include</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #080;" class=3D"styled-by-prettify">&lt;string&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Types</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Purr</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">tuple</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Types</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">...&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">get</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>get</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;i&=
gt;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">t</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">get=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;i&gt;<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">t</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Purr</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">double</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; p</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;()</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; p</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;()</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">4.5</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; p</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #0=
66;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"meo=
w"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> <br></span></div></code></div><=
br>Works in MSVC2013, GCC 4.9.0 and Clang 3.3: <a href=3D"http://goo.gl/MPH=
hMb">http://goo.gl/MPHhMb</a><br></pre>(Although, I can still imagine that =
it's somehow non-standard, but it's just formality after major compilers ac=
cept it :) )<br><br>A bit more for constexpr parameters: I love promoting e=
very possible computation to compile time, after all, noone expects to gene=
rate (release) code that adds 2+2 at runtime for "int i =3D 2+2;". If the c=
onstexpr parameters could mean to allow for generating a runtime
 and a "compile-time" versions of the function, I'd be very interested. Exa=
mple:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">bool opt1, constexpr bool op=
t2</span><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>&nbsp;&nbsp;&nbsp; </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">opt1</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"> lengtyS=
tuff();<br>&nbsp;&nbsp;&nbsp; moreStuff();<br>&nbsp;&nbsp;&nbsp; if (opt2</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">) stuffstuff=
();<br>&nbsp;&nbsp;&nbsp; evenMoreStuff();&nbsp;&nbsp;&nbsp; <br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp;&nbsp;&nbsp; bool userChoice1 </span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">=3D askUser();<br>&nbsp;&nbsp;&=
nbsp; bool</span></code> userChoice2 =3D askUser();<br>&nbsp; &nbsp; </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">foo</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><code class=3D"=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">user=
Choice</span></code><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">1, </span><code class=3D"prettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">userChoice2</span></code><span style=3D"color: #660=
;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">//generates code with 2 branch instructions</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; foo</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">true</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> false</span><code class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify=
">); //no branch instruction, aka "foo&lt;true, false&gt;"<br>&nbsp;&nbsp;&=
nbsp; foo(userChoice1, true); //1 branch instr, aka "foo&lt;true&gt;(userCh=
oice1)"<br>}<br></span></code></code></div></code></div>(In the middle of t=
ight loops, this can matter quite a lot.)<br><br>Regards, Robert<br><br></d=
iv>

<p></p>

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

------=_Part_2232_25312049.1398956411510--

.

------=_Part_3034_26215269.1402338424947
Content-Type: text/plain; charset=UTF-8

Hello,

Do you know if any progress has been made regarding your idea? I've ran
into the exact same problem, I was thinking the tuple syntax for accessing
elements was kind of complicated so I tried to see what the limitations
were for having a subscript operator and came to the conclusion that C++
would need something like constexpr function parameters... which brought me
to this post.

On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>
> Hello everyone!
> Lately I've been concerned with how we access tuple elements.
> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
> What I would really like to be able to write is 't[0]'.
> For this we need constexpr function parameters. So we can define
> operator[] as follows:
> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>     return std::get<i>(*this);
> }
> (or something similar)
>
> I think this would help not only for tuples.
> For example, it is not possible today to pass arbitrary constexpr objects
> to functions because you must pass them as a template parameter.
> Template parameters must be an int/char/typename or the like. I think this
> really limits constexpr objects in terms of usability.
>
> As I see it, we can only return and operate on constexpr objects, but we
> can't pass them around and maintain their "constexprness".
> For example here's a silly example:
> void foo(constexpr int i) {
>     std::array<int, i> arr;
> }
>
> What do you think?
>

--

---
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_3034_26215269.1402338424947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br><br>Do you know if any progress has been made re=
garding your idea? I've ran into the exact same problem, I was thinking the=
 tuple syntax for accessing elements was kind of complicated so I tried to =
see what the limitations were for having a subscript operator and came to t=
he conclusion that C++ would need something like constexpr function paramet=
ers... which brought me to this post.<br><br>On Monday, April 15, 2013 9:43=
:21 AM UTC-7, talz...@gmail.com wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">Hello everyone!&nbsp;<div>Lately I've been concerned with how we ac=
cess tuple elements.</div><div>The syntax 'std::get&lt;0&gt;(t)' seems high=
ly unintuitive to me.<div>What I would really like to be able to write is '=
t[0]'.</div></div><div>For this we need constexpr function parameters. So w=
e can define operator[] as follows:</div><div>auto operator[] (constexpr in=
t i) -&gt; decltype(std::get&lt;i&gt;(*this)) {</div><div>&nbsp; &nbsp; ret=
urn std::get&lt;i&gt;(*this);</div><div>}</div><div>(or something similar)<=
/div><div><br></div><div>I think this would help not only for tuples.</div>=
<div>For example, it is not possible today to pass arbitrary constexpr obje=
cts to functions because you must pass them as a template parameter.</div><=
div>Template parameters must be an int/char/typename or the like. I think t=
his really limits constexpr objects in terms of usability.</div><div><br></=
div><div>As I see it, we can only return and operate on constexpr objects, =
but we can't pass them around and maintain their "constexprness".</div><div=
>For example here's a silly example:</div><div>void foo(constexpr int i) {<=
/div><div>&nbsp; &nbsp; std::array&lt;int, i&gt; arr;</div><div>}</div><div=
><br></div><div>What do you think?</div></blockquote></div>

<p></p>

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

------=_Part_3034_26215269.1402338424947--

.

------=_Part_3136_2912450.1402404994382
Content-Type: text/plain; charset=UTF-8

I'm not aware of any progress..
I still think it's a good idea

On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>
> Hello,
>
> Do you know if any progress has been made regarding your idea? I've ran
> into the exact same problem, I was thinking the tuple syntax for accessing
> elements was kind of complicated so I tried to see what the limitations
> were for having a subscript operator and came to the conclusion that C++
> would need something like constexpr function parameters... which brought me
> to this post.
>
> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>
>> Hello everyone!
>> Lately I've been concerned with how we access tuple elements.
>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>> What I would really like to be able to write is 't[0]'.
>> For this we need constexpr function parameters. So we can define
>> operator[] as follows:
>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>     return std::get<i>(*this);
>> }
>> (or something similar)
>>
>> I think this would help not only for tuples.
>> For example, it is not possible today to pass arbitrary constexpr objects
>> to functions because you must pass them as a template parameter.
>> Template parameters must be an int/char/typename or the like. I think
>> this really limits constexpr objects in terms of usability.
>>
>> As I see it, we can only return and operate on constexpr objects, but we
>> can't pass them around and maintain their "constexprness".
>> For example here's a silly example:
>> void foo(constexpr int i) {
>>     std::array<int, i> arr;
>> }
>>
>> What do you think?
>>
>

--

---
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_3136_2912450.1402404994382
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm not aware of any progress..<br>I still think it's a go=
od idea<br><br>On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hello,<br=
><br>Do you know if any progress has been made regarding your idea? I've ra=
n into the exact same problem, I was thinking the tuple syntax for accessin=
g elements was kind of complicated so I tried to see what the limitations w=
ere for having a subscript operator and came to the conclusion that C++ wou=
ld need something like constexpr function parameters... which brought me to=
 this post.<br><br>On Monday, April 15, 2013 9:43:21 AM UTC-7, <a>talz...@g=
mail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone!&=
nbsp;<div>Lately I've been concerned with how we access tuple elements.</di=
v><div>The syntax 'std::get&lt;0&gt;(t)' seems highly unintuitive to me.<di=
v>What I would really like to be able to write is 't[0]'.</div></div><div>F=
or this we need constexpr function parameters. So we can define operator[] =
as follows:</div><div>auto operator[] (constexpr int i) -&gt; decltype(std:=
:get&lt;i&gt;(*this)) {</div><div>&nbsp; &nbsp; return std::get&lt;i&gt;(*t=
his);</div><div>}</div><div>(or something similar)</div><div><br></div><div=
>I think this would help not only for tuples.</div><div>For example, it is =
not possible today to pass arbitrary constexpr objects to functions because=
 you must pass them as a template parameter.</div><div>Template parameters =
must be an int/char/typename or the like. I think this really limits conste=
xpr objects in terms of usability.</div><div><br></div><div>As I see it, we=
 can only return and operate on constexpr objects, but we can't pass them a=
round and maintain their "constexprness".</div><div>For example here's a si=
lly example:</div><div>void foo(constexpr int i) {</div><div>&nbsp; &nbsp; =
std::array&lt;int, i&gt; arr;</div><div>}</div><div><br></div><div>What do =
you think?</div></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_3136_2912450.1402404994382--

.

------=_Part_2989_980485145.1422381061043
Content-Type: multipart/alternative;
 boundary="----=_Part_2990_1371808584.1422381061043"

------=_Part_2990_1371808584.1422381061043
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Me too. I was going to propose it but got too much work to do nowdays. You=
=20
could also look my suggestion here=20
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/Some=
$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
..

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =D0=
=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0:
>
> I'm not aware of any progress..
> I still think it's a good idea
>
> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>>
>> Hello,
>>
>> Do you know if any progress has been made regarding your idea? I've ran=
=20
>> into the exact same problem, I was thinking the tuple syntax for accessi=
ng=20
>> elements was kind of complicated so I tried to see what the limitations=
=20
>> were for having a subscript operator and came to the conclusion that C++=
=20
>> would need something like constexpr function parameters... which brought=
 me=20
>> to this post.
>>
>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>>
>>> Hello everyone!=20
>>> Lately I've been concerned with how we access tuple elements.
>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>>> What I would really like to be able to write is 't[0]'.
>>> For this we need constexpr function parameters. So we can define=20
>>> operator[] as follows:
>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>>     return std::get<i>(*this);
>>> }
>>> (or something similar)
>>>
>>> I think this would help not only for tuples.
>>> For example, it is not possible today to pass arbitrary constexpr=20
>>> objects to functions because you must pass them as a template parameter=
..
>>> Template parameters must be an int/char/typename or the like. I think=
=20
>>> this really limits constexpr objects in terms of usability.
>>>
>>> As I see it, we can only return and operate on constexpr objects, but w=
e=20
>>> can't pass them around and maintain their "constexprness".
>>> For example here's a silly example:
>>> void foo(constexpr int i) {
>>>     std::array<int, i> arr;
>>> }
>>>
>>> What do you think?
>>>
>>

--=20

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

------=_Part_2990_1371808584.1422381061043
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Me too. I was going to propose it but got too much work to=
 do nowdays. You could also look my suggestion <a href=3D"https://groups.go=
ogle.com/a/isocpp.org/forum/#!searchin/std-proposals/Some$20constexpr/std-p=
roposals/B5R4IsLgRgs/hjE78zL_qo8J">here</a>.<br><br>=D0=B2=D1=82=D0=BE=D1=
=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =D0=B3., 15:56:34 UTC+3, =
talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">I'm not aware of any progress..<b=
r>I still think it's a good idea<br><br>On Monday, June 9, 2014 9:27:05 PM =
UTC+3, Achille Roussel wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Hello,<br><br>Do you know if any progress has been made regardin=
g your idea? I've ran into the exact same problem, I was thinking the tuple=
 syntax for accessing elements was kind of complicated so I tried to see wh=
at the limitations were for having a subscript operator and came to the con=
clusion that C++ would need something like constexpr function parameters...=
 which brought me to this post.<br><br>On Monday, April 15, 2013 9:43:21 AM=
 UTC-7, <a>talz...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">Hello everyone!&nbsp;<div>Lately I've been concerned with how we access=
 tuple elements.</div><div>The syntax 'std::get&lt;0&gt;(t)' seems highly u=
nintuitive to me.<div>What I would really like to be able to write is 't[0]=
'.</div></div><div>For this we need constexpr function parameters. So we ca=
n define operator[] as follows:</div><div>auto operator[] (constexpr int i)=
 -&gt; decltype(std::get&lt;i&gt;(*this)) {</div><div>&nbsp; &nbsp; return =
std::get&lt;i&gt;(*this);</div><div>}</div><div>(or something similar)</div=
><div><br></div><div>I think this would help not only for tuples.</div><div=
>For example, it is not possible today to pass arbitrary constexpr objects =
to functions because you must pass them as a template parameter.</div><div>=
Template parameters must be an int/char/typename or the like. I think this =
really limits constexpr objects in terms of usability.</div><div><br></div>=
<div>As I see it, we can only return and operate on constexpr objects, but =
we can't pass them around and maintain their "constexprness".</div><div>For=
 example here's a silly example:</div><div>void foo(constexpr int i) {</div=
><div>&nbsp; &nbsp; std::array&lt;int, i&gt; arr;</div><div>}</div><div><br=
></div><div>What do you think?</div></blockquote></div></blockquote></div><=
/blockquote></div>

<p></p>

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

------=_Part_2990_1371808584.1422381061043--
------=_Part_2989_980485145.1422381061043--

.

------=_Part_668_775096183.1422381367899
Content-Type: multipart/alternative;
 boundary="----=_Part_669_405744979.1422381367899"

------=_Part_669_405744979.1422381367899
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

But I suppose this is because people are rarely interested in the=20
preprocessor and meta-programming.

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=B0=D1=
=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0:
>
> Me too. I was going to propose it but got too much work to do nowdays. Yo=
u=20
> could also look my suggestion here=20
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/So=
me$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
> .
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =
=D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>
>> I'm not aware of any progress..
>> I still think it's a good idea
>>
>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>>>
>>> Hello,
>>>
>>> Do you know if any progress has been made regarding your idea? I've ran=
=20
>>> into the exact same problem, I was thinking the tuple syntax for access=
ing=20
>>> elements was kind of complicated so I tried to see what the limitations=
=20
>>> were for having a subscript operator and came to the conclusion that C+=
+=20
>>> would need something like constexpr function parameters... which brough=
t me=20
>>> to this post.
>>>
>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>>>
>>>> Hello everyone!=20
>>>> Lately I've been concerned with how we access tuple elements.
>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>>>> What I would really like to be able to write is 't[0]'.
>>>> For this we need constexpr function parameters. So we can define=20
>>>> operator[] as follows:
>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>>>     return std::get<i>(*this);
>>>> }
>>>> (or something similar)
>>>>
>>>> I think this would help not only for tuples.
>>>> For example, it is not possible today to pass arbitrary constexpr=20
>>>> objects to functions because you must pass them as a template paramete=
r.
>>>> Template parameters must be an int/char/typename or the like. I think=
=20
>>>> this really limits constexpr objects in terms of usability.
>>>>
>>>> As I see it, we can only return and operate on constexpr objects, but=
=20
>>>> we can't pass them around and maintain their "constexprness".
>>>> For example here's a silly example:
>>>> void foo(constexpr int i) {
>>>>     std::array<int, i> arr;
>>>> }
>>>>
>>>> What do you think?
>>>>
>>>

--=20

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

------=_Part_669_405744979.1422381367899
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">But I suppose this is because people are rarely interested=
 in the preprocessor and meta-programming.<br><br>=D0=B2=D1=82=D0=BE=D1=80=
=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 1=
9:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Me too. I was going to prop=
ose it but got too much work to do nowdays. You could also look my suggesti=
on <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!searchin/std-p=
roposals/Some$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google=
..com/a/isocpp.org/forum/#!searchin/std-proposals/Some$20constexpr/std-propo=
sals/B5R4IsLgRgs/hjE78zL_qo8J';return true;" onclick=3D"this.href=3D'https:=
//groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/Some$20cons=
texpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J';return true;">here</a>.<br><b=
r>=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =
=D0=B3., 15:56:34 UTC+3, <a>talz...@gmail.com</a> =D0=BD=D0=B0=D0=BF=D0=B8=
=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I'm n=
ot aware of any progress..<br>I still think it's a good idea<br><br>On Mond=
ay, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>Do you know if any pr=
ogress has been made regarding your idea? I've ran into the exact same prob=
lem, I was thinking the tuple syntax for accessing elements was kind of com=
plicated so I tried to see what the limitations were for having a subscript=
 operator and came to the conclusion that C++ would need something like con=
stexpr function parameters... which brought me to this post.<br><br>On Mond=
ay, April 15, 2013 9:43:21 AM UTC-7, <a>talz...@gmail.com</a> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">Hello everyone!&nbsp;<div>Lately I've been=
 concerned with how we access tuple elements.</div><div>The syntax 'std::ge=
t&lt;0&gt;(t)' seems highly unintuitive to me.<div>What I would really like=
 to be able to write is 't[0]'.</div></div><div>For this we need constexpr =
function parameters. So we can define operator[] as follows:</div><div>auto=
 operator[] (constexpr int i) -&gt; decltype(std::get&lt;i&gt;(*this)) {</d=
iv><div>&nbsp; &nbsp; return std::get&lt;i&gt;(*this);</div><div>}</div><di=
v>(or something similar)</div><div><br></div><div>I think this would help n=
ot only for tuples.</div><div>For example, it is not possible today to pass=
 arbitrary constexpr objects to functions because you must pass them as a t=
emplate parameter.</div><div>Template parameters must be an int/char/typena=
me or the like. I think this really limits constexpr objects in terms of us=
ability.</div><div><br></div><div>As I see it, we can only return and opera=
te on constexpr objects, but we can't pass them around and maintain their "=
constexprness".</div><div>For example here's a silly example:</div><div>voi=
d foo(constexpr int i) {</div><div>&nbsp; &nbsp; std::array&lt;int, i&gt; a=
rr;</div><div>}</div><div><br></div><div>What do you think?</div></blockquo=
te></div></blockquote></div></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_669_405744979.1422381367899--
------=_Part_668_775096183.1422381367899--

.

I don't get it.  What has this proposal to do with the preprocessor ?

On 1/27/15, sasho648 <sasho648@mail.bg> wrote:
> But I suppose this is because people are rarely interested in the
> preprocessor and meta-programming.
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=B0=
=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:
>>
>> Me too. I was going to propose it but got too much work to do nowdays. Y=
ou
>>
>> could also look my suggestion here
>> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/S=
ome$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
>> .
>>
>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =
=D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>>
>>> I'm not aware of any progress..
>>> I still think it's a good idea
>>>
>>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>>>>
>>>> Hello,
>>>>
>>>> Do you know if any progress has been made regarding your idea? I've ra=
n
>>>>
>>>> into the exact same problem, I was thinking the tuple syntax for
>>>> accessing
>>>> elements was kind of complicated so I tried to see what the limitation=
s
>>>>
>>>> were for having a subscript operator and came to the conclusion that C=
++
>>>>
>>>> would need something like constexpr function parameters... which broug=
ht
>>>> me
>>>> to this post.
>>>>
>>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>>>>
>>>>> Hello everyone!
>>>>> Lately I've been concerned with how we access tuple elements.
>>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>>>>> What I would really like to be able to write is 't[0]'.
>>>>> For this we need constexpr function parameters. So we can define
>>>>> operator[] as follows:
>>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>>>>     return std::get<i>(*this);
>>>>> }
>>>>> (or something similar)
>>>>>
>>>>> I think this would help not only for tuples.
>>>>> For example, it is not possible today to pass arbitrary constexpr
>>>>> objects to functions because you must pass them as a template
>>>>> parameter.
>>>>> Template parameters must be an int/char/typename or the like. I think
>>>>> this really limits constexpr objects in terms of usability.
>>>>>
>>>>> As I see it, we can only return and operate on constexpr objects, but
>>>>> we can't pass them around and maintain their "constexprness".
>>>>> For example here's a silly example:
>>>>> void foo(constexpr int i) {
>>>>>     std::array<int, i> arr;
>>>>> }
>>>>>
>>>>> What do you think?
>>>>>
>>>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

.

As for metaprogramming, I believe there is a LOT of interest!

On 1/27/15, sasho648 <sasho648@mail.bg> wrote:
> But I suppose this is because people are rarely interested in the
> preprocessor and meta-programming.
>
> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=B0=
=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:
>>
>> Me too. I was going to propose it but got too much work to do nowdays. Y=
ou
>>
>> could also look my suggestion here
>> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/S=
ome$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
>> .
>>
>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =
=D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>>
>>> I'm not aware of any progress..
>>> I still think it's a good idea
>>>
>>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>>>>
>>>> Hello,
>>>>
>>>> Do you know if any progress has been made regarding your idea? I've ra=
n
>>>>
>>>> into the exact same problem, I was thinking the tuple syntax for
>>>> accessing
>>>> elements was kind of complicated so I tried to see what the limitation=
s
>>>>
>>>> were for having a subscript operator and came to the conclusion that C=
++
>>>>
>>>> would need something like constexpr function parameters... which broug=
ht
>>>> me
>>>> to this post.
>>>>
>>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>>>>
>>>>> Hello everyone!
>>>>> Lately I've been concerned with how we access tuple elements.
>>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>>>>> What I would really like to be able to write is 't[0]'.
>>>>> For this we need constexpr function parameters. So we can define
>>>>> operator[] as follows:
>>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>>>>     return std::get<i>(*this);
>>>>> }
>>>>> (or something similar)
>>>>>
>>>>> I think this would help not only for tuples.
>>>>> For example, it is not possible today to pass arbitrary constexpr
>>>>> objects to functions because you must pass them as a template
>>>>> parameter.
>>>>> Template parameters must be an int/char/typename or the like. I think
>>>>> this really limits constexpr objects in terms of usability.
>>>>>
>>>>> As I see it, we can only return and operate on constexpr objects, but
>>>>> we can't pass them around and maintain their "constexprness".
>>>>> For example here's a silly example:
>>>>> void foo(constexpr int i) {
>>>>>     std::array<int, i> arr;
>>>>> }
>>>>>
>>>>> What do you think?
>>>>>
>>>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

.

Sorry for top-posting. I want to bring this issue again, please let's
make some effort to find a solution since it's important.

This would be very useful allowing lambdas in TMP, and also for static_asse=
rts.
There is also a specific but yet real-life issue, which is intrinsics:
some intrinsics require arguments to be literals since those arguments
will become immediates in the associated instruction.
I'm trying to write an AES related program using Intel's AES-NI for
which gcc (and I think MSVC) have intrinsics, such as
_mm_aeskeygenassist_si128 ("the last argument must be an 8-bit
immediate").
There is no C++ way of doing this program with compile time loop
unrolling. If I would be able to do
     Loop<0, 9>::operate([ ](constexpr unsigned int index) {
the_intrinsic(index); });
with the constexpr argument transformed into a non-type template
argument, then the problem would be solved.
I could also say static_assert(index < 10) and it would work too.

Would memoization be an issue here? Is that what Nicol Bolas refers
to? Let's start the discussion again.

Thanks,

    Daniel.


On Tue, Jan 27, 2015 at 3:44 PM, Douglas Boffey
<douglas.boffey@gmail.com> wrote:
> As for metaprogramming, I believe there is a LOT of interest!
>
> On 1/27/15, sasho648 <sasho648@mail.bg> wrote:
>> But I suppose this is because people are rarely interested in the
>> preprocessor and meta-programming.
>>
>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=B0=
=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:
>>>
>>> Me too. I was going to propose it but got too much work to do nowdays. =
You
>>>
>>> could also look my suggestion here
>>> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/=
Some$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
>>> .
>>>
>>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014 =
=D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>>>
>>>> I'm not aware of any progress..
>>>> I still think it's a good idea
>>>>
>>>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Do you know if any progress has been made regarding your idea? I've r=
an
>>>>>
>>>>> into the exact same problem, I was thinking the tuple syntax for
>>>>> accessing
>>>>> elements was kind of complicated so I tried to see what the limitatio=
ns
>>>>>
>>>>> were for having a subscript operator and came to the conclusion that =
C++
>>>>>
>>>>> would need something like constexpr function parameters... which brou=
ght
>>>>> me
>>>>> to this post.
>>>>>
>>>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>>>>>
>>>>>> Hello everyone!
>>>>>> Lately I've been concerned with how we access tuple elements.
>>>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>>>>>> What I would really like to be able to write is 't[0]'.
>>>>>> For this we need constexpr function parameters. So we can define
>>>>>> operator[] as follows:
>>>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>>>>>     return std::get<i>(*this);
>>>>>> }
>>>>>> (or something similar)
>>>>>>
>>>>>> I think this would help not only for tuples.
>>>>>> For example, it is not possible today to pass arbitrary constexpr
>>>>>> objects to functions because you must pass them as a template
>>>>>> parameter.
>>>>>> Template parameters must be an int/char/typename or the like. I thin=
k
>>>>>> this really limits constexpr objects in terms of usability.
>>>>>>
>>>>>> As I see it, we can only return and operate on constexpr objects, bu=
t
>>>>>> we can't pass them around and maintain their "constexprness".
>>>>>> For example here's a silly example:
>>>>>> void foo(constexpr int i) {
>>>>>>     std::array<int, i> arr;
>>>>>> }
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2AuH6uR3pjoonsJ_OiT0kQ%2BdPEEyBL9_TuCC97i=
q0ehg%40mail.gmail.com.

.

On Wed, Apr 6, 2016 at 1:31 PM, dgutson . <danielgutson@gmail.com> wrote:
> Sorry for top-posting. I want to bring this issue again, please let's
> make some effort to find a solution since it's important.

Sorry, I think I actually found a workaround with generic lambdas:

template <class Function>
void fun(Function f)
{
   f(std::integral_constant<int, 1>());
}

int main()
{
    fun([](auto x){ std::cout << decltype(x)::value << std::endl; });
}

I will try my code using this idea; is this a solution for the OP?

>
> This would be very useful allowing lambdas in TMP, and also for static_as=
serts.
> There is also a specific but yet real-life issue, which is intrinsics:
> some intrinsics require arguments to be literals since those arguments
> will become immediates in the associated instruction.
> I'm trying to write an AES related program using Intel's AES-NI for
> which gcc (and I think MSVC) have intrinsics, such as
> _mm_aeskeygenassist_si128 ("the last argument must be an 8-bit
> immediate").
> There is no C++ way of doing this program with compile time loop
> unrolling. If I would be able to do
>      Loop<0, 9>::operate([ ](constexpr unsigned int index) {
> the_intrinsic(index); });
> with the constexpr argument transformed into a non-type template
> argument, then the problem would be solved.
> I could also say static_assert(index < 10) and it would work too.
>
> Would memoization be an issue here? Is that what Nicol Bolas refers
> to? Let's start the discussion again.
>
> Thanks,
>
>     Daniel.
>
>
> On Tue, Jan 27, 2015 at 3:44 PM, Douglas Boffey
> <douglas.boffey@gmail.com> wrote:
>> As for metaprogramming, I believe there is a LOT of interest!
>>
>> On 1/27/15, sasho648 <sasho648@mail.bg> wrote:
>>> But I suppose this is because people are rarely interested in the
>>> preprocessor and meta-programming.
>>>
>>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=B0=
=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=D0=
=B8=D1=81=D0=B0:
>>>>
>>>> Me too. I was going to propose it but got too much work to do nowdays.=
 You
>>>>
>>>> could also look my suggestion here
>>>> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals=
/Some$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
>>>> .
>>>>
>>>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 2014=
 =D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:
>>>>>
>>>>> I'm not aware of any progress..
>>>>> I still think it's a good idea
>>>>>
>>>>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Do you know if any progress has been made regarding your idea? I've =
ran
>>>>>>
>>>>>> into the exact same problem, I was thinking the tuple syntax for
>>>>>> accessing
>>>>>> elements was kind of complicated so I tried to see what the limitati=
ons
>>>>>>
>>>>>> were for having a subscript operator and came to the conclusion that=
 C++
>>>>>>
>>>>>> would need something like constexpr function parameters... which bro=
ught
>>>>>> me
>>>>>> to this post.
>>>>>>
>>>>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrote:
>>>>>>>
>>>>>>> Hello everyone!
>>>>>>> Lately I've been concerned with how we access tuple elements.
>>>>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>>>>>>> What I would really like to be able to write is 't[0]'.
>>>>>>> For this we need constexpr function parameters. So we can define
>>>>>>> operator[] as follows:
>>>>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>>>>>>     return std::get<i>(*this);
>>>>>>> }
>>>>>>> (or something similar)
>>>>>>>
>>>>>>> I think this would help not only for tuples.
>>>>>>> For example, it is not possible today to pass arbitrary constexpr
>>>>>>> objects to functions because you must pass them as a template
>>>>>>> parameter.
>>>>>>> Template parameters must be an int/char/typename or the like. I thi=
nk
>>>>>>> this really limits constexpr objects in terms of usability.
>>>>>>>
>>>>>>> As I see it, we can only return and operate on constexpr objects, b=
ut
>>>>>>> we can't pass them around and maintain their "constexprness".
>>>>>>> For example here's a silly example:
>>>>>>> void foo(constexpr int i) {
>>>>>>>     std::array<int, i> arr;
>>>>>>> }
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Grou=
ps
>>> "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send =
an
>>> email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n 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-prop=
osals/.
>
>
>
> --
> Who=E2=80=99s got the sweetest disposition?
> One guess, that=E2=80=99s who?
> Who=E2=80=99d never, ever start an argument?
> Who never shows a bit of temperament?
> Who's never wrong but always right?
> Who'd never dream of starting a fight?
> Who get stuck with all the bad luck?



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-0WtL3wcEfqZxzi8qp81Y7N6JsmFLDMRPA-MnQZ8R_=
88g%40mail.gmail.com.

.

------=_Part_413_1871316911.1459961684036
Content-Type: multipart/alternative;
 boundary="----=_Part_414_1080670096.1459961684036"

------=_Part_414_1080670096.1459961684036
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, April 6, 2016 at 11:32:00 AM UTC-5, dgutson wrote:
>
> Sorry for top-posting. I want to bring this issue again, please let's=20
> make some effort to find a solution since it's important.=20
>
> This would be very useful allowing lambdas in TMP, and also for=20
> static_asserts.=20
> There is also a specific but yet real-life issue, which is intrinsics:=20
> some intrinsics require arguments to be literals since those arguments=20
> will become immediates in the associated instruction.=20
> I'm trying to write an AES related program using Intel's AES-NI for=20
> which gcc (and I think MSVC) have intrinsics, such as=20
> _mm_aeskeygenassist_si128 ("the last argument must be an 8-bit=20
> immediate").=20
> There is no C++ way of doing this program with compile time loop=20
> unrolling. If I would be able to do=20
>      Loop<0, 9>::operate([ ](constexpr unsigned int index) {=20
> the_intrinsic(index); });=20
> with the constexpr argument transformed into a non-type template=20
> argument, then the problem would be solved.=20
> I could also say static_assert(index < 10) and it would work too.=20
>

Why wouldn't integral constants work? You can already write this:

template<class IntegralConstant>
void foo(IntegralConstant index)
{
    static_assert(index < 10);
}
foo(std::integral_constant<unsigned int, 9>{});

And using user-defined literals, the function could be called like this:

foo(9_c);

So your loop unrolling could be written like this:

Loop<0, 9>::operate([ ](auto index) { the_intrinsic(index); });=20

If for some reason, the compiler doesn't call the implicit conversions with=
=20
the intrinsic(very unlikely), then it could be written like this as well:

Loop<0, 9>::operate([ ](auto I) {=20
    static constexpr unsigned int index =3D I;
    the_intrinsic(index);=20
});=20

=20

>
> Would memoization be an issue here? Is that what Nicol Bolas refers=20
> to? Let's start the discussion again.=20
>
> Thanks,=20
>
>     Daniel.=20
>
>
> On Tue, Jan 27, 2015 at 3:44 PM, Douglas Boffey=20
> <douglas...@gmail.com <javascript:>> wrote:=20
> > As for metaprogramming, I believe there is a LOT of interest!=20
> >=20
> > On 1/27/15, sasho648 <sash...@mail.bg <javascript:>> wrote:=20
> >> But I suppose this is because people are rarely interested in the=20
> >> preprocessor and meta-programming.=20
> >>=20
> >> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:=20
> >>>=20
> >>> Me too. I was going to propose it but got too much work to do nowdays=
..=20
> You=20
> >>>=20
> >>> could also look my suggestion here=20
> >>> <
> https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/Som=
e$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>=20
>
> >>> .=20
> >>>=20
> >>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 201=
4 =D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0:=20
> >>>>=20
> >>>> I'm not aware of any progress..=20
> >>>> I still think it's a good idea=20
> >>>>=20
> >>>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:=20
> >>>>>=20
> >>>>> Hello,=20
> >>>>>=20
> >>>>> Do you know if any progress has been made regarding your idea? I've=
=20
> ran=20
> >>>>>=20
> >>>>> into the exact same problem, I was thinking the tuple syntax for=20
> >>>>> accessing=20
> >>>>> elements was kind of complicated so I tried to see what the=20
> limitations=20
> >>>>>=20
> >>>>> were for having a subscript operator and came to the conclusion tha=
t=20
> C++=20
> >>>>>=20
> >>>>> would need something like constexpr function parameters... which=20
> brought=20
> >>>>> me=20
> >>>>> to this post.=20
> >>>>>=20
> >>>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com=20
> wrote:=20
> >>>>>>=20
> >>>>>> Hello everyone!=20
> >>>>>> Lately I've been concerned with how we access tuple elements.=20
> >>>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.=20
> >>>>>> What I would really like to be able to write is 't[0]'.=20
> >>>>>> For this we need constexpr function parameters. So we can define=
=20
> >>>>>> operator[] as follows:=20
> >>>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) =
{=20
> >>>>>>     return std::get<i>(*this);=20
> >>>>>> }=20
> >>>>>> (or something similar)=20
> >>>>>>=20
> >>>>>> I think this would help not only for tuples.=20
> >>>>>> For example, it is not possible today to pass arbitrary constexpr=
=20
> >>>>>> objects to functions because you must pass them as a template=20
> >>>>>> parameter.=20
> >>>>>> Template parameters must be an int/char/typename or the like. I=20
> think=20
> >>>>>> this really limits constexpr objects in terms of usability.=20
> >>>>>>=20
> >>>>>> As I see it, we can only return and operate on constexpr objects,=
=20
> but=20
> >>>>>> we can't pass them around and maintain their "constexprness".=20
> >>>>>> For example here's a silly example:=20
> >>>>>> void foo(constexpr int i) {=20
> >>>>>>     std::array<int, i> arr;=20
> >>>>>> }=20
> >>>>>>=20
> >>>>>> What do you think?=20
> >>>>>>=20
> >>>>>=20
> >>=20
> >> --=20
> >>=20
> >> ---=20
> >> You received this message because you are subscribed to the Google=20
> Groups=20
> >> "ISO C++ Standard - Future Proposals" group.=20
> >> To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> >> email to std-proposal...@isocpp.org <javascript:>.=20
> >> To post to this group, send email to std-pr...@isocpp.org <javascript:=
>.=20
>
> >> Visit this group at=20
> >> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >>=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>
>
>
> --=20
> Who=E2=80=99s got the sweetest disposition?=20
> One guess, that=E2=80=99s who?=20
> Who=E2=80=99d never, ever start an argument?=20
> Who never shows a bit of temperament?=20
> Who's never wrong but always right?=20
> Who'd never dream of starting a fight?=20
> Who get stuck with all the bad luck?=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3810042a-253b-4aa0-84e9-72e7a79058b2%40isocpp.or=
g.

------=_Part_414_1080670096.1459961684036
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, April 6, 2016 at 11:32:00 AM UTC-5, =
dgutson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Sorry for top-po=
sting. I want to bring this issue again, please let&#39;s
<br>make some effort to find a solution since it&#39;s important.
<br>
<br>This would be very useful allowing lambdas in TMP, and also for static_=
asserts.
<br>There is also a specific but yet real-life issue, which is intrinsics:
<br>some intrinsics require arguments to be literals since those arguments
<br>will become immediates in the associated instruction.
<br>I&#39;m trying to write an AES related program using Intel&#39;s AES-NI=
 for
<br>which gcc (and I think MSVC) have intrinsics, such as
<br>_mm_aeskeygenassist_si128 (&quot;the last argument must be an 8-bit
<br>immediate&quot;).
<br>There is no C++ way of doing this program with compile time loop
<br>unrolling. If I would be able to do
<br>=C2=A0 =C2=A0 =C2=A0Loop&lt;0, 9&gt;::operate([ ](constexpr unsigned in=
t index) {
<br>the_intrinsic(index); });
<br>with the constexpr argument transformed into a non-type template
<br>argument, then the problem would be solved.
<br>I could also say static_assert(index &lt; 10) and it would work too.
<br></blockquote><div><br>Why wouldn&#39;t integral constants work? You can=
 already write this:<br><br>template&lt;class IntegralConstant&gt;<br>void =
foo(IntegralConstant index)<br>{<br>=C2=A0=C2=A0=C2=A0 static_assert(index =
&lt; 10);<br>}<br>foo(std::integral_constant&lt;unsigned int, 9&gt;{});<br>=
<br>And using user-defined literals, the function could be called like this=
:<br><br>foo(9_c);<br><br>So your loop unrolling could be written like this=
:<br><br>Loop&lt;0, 9&gt;::operate([ ](auto index) {
the_intrinsic(index); });
<br><br>If for some reason, the compiler doesn&#39;t call the implicit conv=
ersions with the intrinsic(very unlikely), then it could be written like th=
is as well:<br><br>Loop&lt;0, 9&gt;::operate([ ](auto I) {
<br>=C2=A0=C2=A0=C2=A0 static constexpr unsigned int index =3D I;<br>=C2=A0=
=C2=A0=C2=A0 the_intrinsic(index); <br>});
<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Would memoization be an issue here? Is that what Nicol Bolas refers
<br>to? Let&#39;s start the discussion again.
<br>
<br>Thanks,
<br>
<br>=C2=A0 =C2=A0 Daniel.
<br>
<br>
<br>On Tue, Jan 27, 2015 at 3:44 PM, Douglas Boffey
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
5FjWUAsAAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">douglas...@gmail.com</a>&gt; wrote:
<br>&gt; As for metaprogramming, I believe there is a LOT of interest!
<br>&gt;
<br>&gt; On 1/27/15, sasho648 &lt;<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"5FjWUAsAAgAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">sash...@mail.bg</a>&gt; wrote:
<br>&gt;&gt; But I suppose this is because people are rarely interested in =
the
<br>&gt;&gt; preprocessor and meta-programming.
<br>&gt;&gt;
<br>&gt;&gt; =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=
=83=D0=B0=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0:
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; Me too. I was going to propose it but got too much work to=
 do nowdays. You
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; could also look my suggestion here
<br>&gt;&gt;&gt; &lt;<a href=3D"https://groups.google.com/a/isocpp.org/foru=
m/#!searchin/std-proposals/Some$20constexpr/std-proposals/B5R4IsLgRgs/hjE78=
zL_qo8J" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/Some=
$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!sear=
chin/std-proposals/Some$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J&=
#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!sear=
chin/<wbr>std-proposals/Some$<wbr>20constexpr/std-proposals/<wbr>B5R4IsLgRg=
s/hjE78zL_qo8J</a>&gt;
<br>&gt;&gt;&gt; .
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=
=BD=D0=B8 2014 =D0=B3., 15:56:34 UTC+3, <a>talz...@gmail.com</a> =D0=BD=D0=
=B0=D0=BF=D0=B8=D1=81=D0=B0:
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt; I&#39;m not aware of any progress..
<br>&gt;&gt;&gt;&gt; I still think it&#39;s a good idea
<br>&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt; On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Rous=
sel wrote:
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt; Hello,
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt; Do you know if any progress has been made regardin=
g your idea? I&#39;ve ran
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt; into the exact same problem, I was thinking the tu=
ple syntax for
<br>&gt;&gt;&gt;&gt;&gt; accessing
<br>&gt;&gt;&gt;&gt;&gt; elements was kind of complicated so I tried to see=
 what the limitations
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt; were for having a subscript operator and came to t=
he conclusion that C++
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt; would need something like constexpr function param=
eters... which brought
<br>&gt;&gt;&gt;&gt;&gt; me
<br>&gt;&gt;&gt;&gt;&gt; to this post.
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt; On Monday, April 15, 2013 9:43:21 AM UTC-7, <a>tal=
z...@gmail.com</a> wrote:
<br>&gt;&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt;&gt; Hello everyone!
<br>&gt;&gt;&gt;&gt;&gt;&gt; Lately I&#39;ve been concerned with how we acc=
ess tuple elements.
<br>&gt;&gt;&gt;&gt;&gt;&gt; The syntax &#39;std::get&lt;0&gt;(t)&#39; seem=
s highly unintuitive to me.
<br>&gt;&gt;&gt;&gt;&gt;&gt; What I would really like to be able to write i=
s &#39;t[0]&#39;.
<br>&gt;&gt;&gt;&gt;&gt;&gt; For this we need constexpr function parameters=
.. So we can define
<br>&gt;&gt;&gt;&gt;&gt;&gt; operator[] as follows:
<br>&gt;&gt;&gt;&gt;&gt;&gt; auto operator[] (constexpr int i) -&gt; declty=
pe(std::get&lt;i&gt;(*this)) {
<br>&gt;&gt;&gt;&gt;&gt;&gt; =C2=A0 =C2=A0 return std::get&lt;i&gt;(*this);
<br>&gt;&gt;&gt;&gt;&gt;&gt; }
<br>&gt;&gt;&gt;&gt;&gt;&gt; (or something similar)
<br>&gt;&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt;&gt; I think this would help not only for tuples.
<br>&gt;&gt;&gt;&gt;&gt;&gt; For example, it is not possible today to pass =
arbitrary constexpr
<br>&gt;&gt;&gt;&gt;&gt;&gt; objects to functions because you must pass the=
m as a template
<br>&gt;&gt;&gt;&gt;&gt;&gt; parameter.
<br>&gt;&gt;&gt;&gt;&gt;&gt; Template parameters must be an int/char/typena=
me or the like. I think
<br>&gt;&gt;&gt;&gt;&gt;&gt; this really limits constexpr objects in terms =
of usability.
<br>&gt;&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt;&gt; As I see it, we can only return and operate on=
 constexpr objects, but
<br>&gt;&gt;&gt;&gt;&gt;&gt; we can&#39;t pass them around and maintain the=
ir &quot;constexprness&quot;.
<br>&gt;&gt;&gt;&gt;&gt;&gt; For example here&#39;s a silly example:
<br>&gt;&gt;&gt;&gt;&gt;&gt; void foo(constexpr int i) {
<br>&gt;&gt;&gt;&gt;&gt;&gt; =C2=A0 =C2=A0 std::array&lt;int, i&gt; arr;
<br>&gt;&gt;&gt;&gt;&gt;&gt; }
<br>&gt;&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt;&gt; What do you think?
<br>&gt;&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;&gt;&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; --
<br>&gt;&gt;
<br>&gt;&gt; ---
<br>&gt;&gt; You received this message because you are subscribed to the Go=
ogle Groups
<br>&gt;&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt;&gt; To unsubscribe from this group and stop receiving emails from =
it, send an
<br>&gt;&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"5FjWUAsAAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#3=
9;;return true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt;&gt; To post to this group, send email to <a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"5FjWUAsAAgAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt;&gt; Visit this group at
<br>&gt;&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-pro=
posals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group=
/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>isocpp.o=
rg/group/std-<wbr>proposals/</a>.
<br>&gt;&gt;
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"5FjWUAsAAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"5FjWUAsAAgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.o=
rg/group/std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/=
isocpp.org/group/std-proposals/&#39;;return true;">http://groups.google.com=
/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.
<br>
<br>
<br>
<br>--=20
<br>Who=E2=80=99s got the sweetest disposition?
<br>One guess, that=E2=80=99s who?
<br>Who=E2=80=99d never, ever start an argument?
<br>Who never shows a bit of temperament?
<br>Who&#39;s never wrong but always right?
<br>Who&#39;d never dream of starting a fight?
<br>Who get stuck with all the bad luck?
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3810042a-253b-4aa0-84e9-72e7a79058b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3810042a-253b-4aa0-84e9-72e7a79058b2=
%40isocpp.org</a>.<br />

------=_Part_414_1080670096.1459961684036--
------=_Part_413_1871316911.1459961684036--

.

On Wed, Apr 6, 2016 at 1:54 PM, Paul Fultz II <pfultz28@gmail.com> wrote:
>
>
> On Wednesday, April 6, 2016 at 11:32:00 AM UTC-5, dgutson wrote:
>>
>> Sorry for top-posting. I want to bring this issue again, please let's
>> make some effort to find a solution since it's important.
>>
>> This would be very useful allowing lambdas in TMP, and also for
>> static_asserts.
>> There is also a specific but yet real-life issue, which is intrinsics:
>> some intrinsics require arguments to be literals since those arguments
>> will become immediates in the associated instruction.
>> I'm trying to write an AES related program using Intel's AES-NI for
>> which gcc (and I think MSVC) have intrinsics, such as
>> _mm_aeskeygenassist_si128 ("the last argument must be an 8-bit
>> immediate").
>> There is no C++ way of doing this program with compile time loop
>> unrolling. If I would be able to do
>>      Loop<0, 9>::operate([ ](constexpr unsigned int index) {
>> the_intrinsic(index); });
>> with the constexpr argument transformed into a non-type template
>> argument, then the problem would be solved.
>> I could also say static_assert(index < 10) and it would work too.
>
>
> Why wouldn't integral constants work? You can already write this:

You are one mail behind :D I just realized about this and posted it,
so let's see what the OP says.

>
> template<class IntegralConstant>
> void foo(IntegralConstant index)
> {
>     static_assert(index < 10);
> }
> foo(std::integral_constant<unsigned int, 9>{});
>
> And using user-defined literals, the function could be called like this:
>
> foo(9_c);
>
> So your loop unrolling could be written like this:
>
> Loop<0, 9>::operate([ ](auto index) { the_intrinsic(index); });
>
> If for some reason, the compiler doesn't call the implicit conversions wi=
th
> the intrinsic(very unlikely), then it could be written like this as well:
>
> Loop<0, 9>::operate([ ](auto I) {
>     static constexpr unsigned int index =3D I;
>     the_intrinsic(index);
> });
>
>
>>
>>
>> Would memoization be an issue here? Is that what Nicol Bolas refers
>> to? Let's start the discussion again.
>>
>> Thanks,
>>
>>     Daniel.
>>
>>
>> On Tue, Jan 27, 2015 at 3:44 PM, Douglas Boffey
>> <douglas...@gmail.com> wrote:
>> > As for metaprogramming, I believe there is a LOT of interest!
>> >
>> > On 1/27/15, sasho648 <sash...@mail.bg> wrote:
>> >> But I suppose this is because people are rarely interested in the
>> >> preprocessor and meta-programming.
>> >>
>> >> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 27 =D1=8F=D0=BD=D1=83=D0=
=B0=D1=80=D0=B8 2015 =D0=B3., 19:51:01 UTC+2, sasho648 =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:
>> >>>
>> >>> Me too. I was going to propose it but got too much work to do nowday=
s.
>> >>> You
>> >>>
>> >>> could also look my suggestion here
>> >>>
>> >>> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposa=
ls/Some$20constexpr/std-proposals/B5R4IsLgRgs/hjE78zL_qo8J>
>> >>> .
>> >>>
>> >>> =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 10 =D1=8E=D0=BD=D0=B8 20=
14 =D0=B3., 15:56:34 UTC+3, talz...@gmail.com =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0:
>> >>>>
>> >>>> I'm not aware of any progress..
>> >>>> I still think it's a good idea
>> >>>>
>> >>>> On Monday, June 9, 2014 9:27:05 PM UTC+3, Achille Roussel wrote:
>> >>>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> Do you know if any progress has been made regarding your idea? I'v=
e
>> >>>>> ran
>> >>>>>
>> >>>>> into the exact same problem, I was thinking the tuple syntax for
>> >>>>> accessing
>> >>>>> elements was kind of complicated so I tried to see what the
>> >>>>> limitations
>> >>>>>
>> >>>>> were for having a subscript operator and came to the conclusion th=
at
>> >>>>> C++
>> >>>>>
>> >>>>> would need something like constexpr function parameters... which
>> >>>>> brought
>> >>>>> me
>> >>>>> to this post.
>> >>>>>
>> >>>>> On Monday, April 15, 2013 9:43:21 AM UTC-7, talz...@gmail.com wrot=
e:
>> >>>>>>
>> >>>>>> Hello everyone!
>> >>>>>> Lately I've been concerned with how we access tuple elements.
>> >>>>>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>> >>>>>> What I would really like to be able to write is 't[0]'.
>> >>>>>> For this we need constexpr function parameters. So we can define
>> >>>>>> operator[] as follows:
>> >>>>>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this))=
 {
>> >>>>>>     return std::get<i>(*this);
>> >>>>>> }
>> >>>>>> (or something similar)
>> >>>>>>
>> >>>>>> I think this would help not only for tuples.
>> >>>>>> For example, it is not possible today to pass arbitrary constexpr
>> >>>>>> objects to functions because you must pass them as a template
>> >>>>>> parameter.
>> >>>>>> Template parameters must be an int/char/typename or the like. I
>> >>>>>> think
>> >>>>>> this really limits constexpr objects in terms of usability.
>> >>>>>>
>> >>>>>> As I see it, we can only return and operate on constexpr objects,
>> >>>>>> but
>> >>>>>> we can't pass them around and maintain their "constexprness".
>> >>>>>> For example here's a silly example:
>> >>>>>> void foo(constexpr int i) {
>> >>>>>>     std::array<int, i> arr;
>> >>>>>> }
>> >>>>>>
>> >>>>>> What do you think?
>> >>>>>>
>> >>>>>
>> >>
>> >> --
>> >>
>> >> ---
>> >> 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, sen=
d
>> >> an
>> >> email to std-proposal...@isocpp.org.
>> >> To post to this group, send email to std-pr...@isocpp.org.
>> >> Visit this group at
>> >> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>> >>
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > Visit this group at
>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>>
>> --
>> Who=E2=80=99s got the sweetest disposition?
>> One guess, that=E2=80=99s who?
>> Who=E2=80=99d never, ever start an argument?
>> Who never shows a bit of temperament?
>> Who's never wrong but always right?
>> Who'd never dream of starting a fight?
>> Who get stuck with all the bad luck?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3810042a-253=
b-4aa0-84e9-72e7a79058b2%40isocpp.org.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFdMc-2%2B_bd4Ph_CT6bH-mNC3%2BWgERO-oXgMS4_8Q_h=
5VuBa1g%40mail.gmail.com.

.

------=_Part_9438_987499489.1492609742919
Content-Type: multipart/alternative;
 boundary="----=_Part_9439_1519702120.1492609742919"

------=_Part_9439_1519702120.1492609742919
Content-Type: text/plain; charset=UTF-8

Hello,

has there been any progress on this topic yet?

Thanks in advance
Jakob

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0f3a5b8c-b906-4f0f-8dd7-7b61a4bbecac%40isocpp.org.

------=_Part_9439_1519702120.1492609742919
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>has there been any progress on t=
his topic yet?</div><div><br></div><div>Thanks in advance</div><div>Jakob</=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0f3a5b8c-b906-4f0f-8dd7-7b61a4bbecac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f3a5b8c-b906-4f0f-8dd7-7b61a4bbecac=
%40isocpp.org</a>.<br />

------=_Part_9439_1519702120.1492609742919--

------=_Part_9438_987499489.1492609742919--

.

------=_Part_3997_1844320418.1504092201210
Content-Type: multipart/alternative;
 boundary="----=_Part_3998_574226699.1504092201211"

------=_Part_3998_574226699.1504092201211
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Id like to see it, and it would be especially great for things like=20
allowing static_assert.=20


Den m=C3=A5ndag 15 april 2013 kl. 18:43:21 UTC+2 skrev talz...@gmail.com:
>
> Hello everyone!=20
> Lately I've been concerned with how we access tuple elements.
> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
> What I would really like to be able to write is 't[0]'.
> For this we need constexpr function parameters. So we can define=20
> operator[] as follows:
> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>     return std::get<i>(*this);
> }
> (or something similar)
>
> I think this would help not only for tuples.
> For example, it is not possible today to pass arbitrary constexpr objects=
=20
> to functions because you must pass them as a template parameter.
> Template parameters must be an int/char/typename or the like. I think thi=
s=20
> really limits constexpr objects in terms of usability.
>
> As I see it, we can only return and operate on constexpr objects, but we=
=20
> can't pass them around and maintain their "constexprness".
> For example here's a silly example:
> void foo(constexpr int i) {
>     std::array<int, i> arr;
> }
>
> What do you think?
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/550d9ed4-1484-48f2-af2b-fb5c82bfe562%40isocpp.or=
g.

------=_Part_3998_574226699.1504092201211
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Id like to see it, and it would be especially great for th=
ings like allowing static_assert.=C2=A0<div><br><div><div><br>Den m=C3=A5nd=
ag 15 april 2013 kl. 18:43:21 UTC+2 skrev talz...@gmail.com:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">Hello everyone!=C2=A0<div>Lately I&#39;ve bee=
n concerned with how we access tuple elements.</div><div>The syntax &#39;st=
d::get&lt;0&gt;(t)&#39; seems highly unintuitive to me.<div>What I would re=
ally like to be able to write is &#39;t[0]&#39;.</div></div><div>For this w=
e need constexpr function parameters. So we can define operator[] as follow=
s:</div><div>auto operator[] (constexpr int i) -&gt; decltype(std::get&lt;i=
&gt;(*this)) {</div><div>=C2=A0 =C2=A0 return std::get&lt;i&gt;(*this);</di=
v><div>}</div><div>(or something similar)</div><div><br></div><div>I think =
this would help not only for tuples.</div><div>For example, it is not possi=
ble today to pass arbitrary constexpr objects to functions because you must=
 pass them as a template parameter.</div><div>Template parameters must be a=
n int/char/typename or the like. I think this really limits constexpr objec=
ts in terms of usability.</div><div><br></div><div>As I see it, we can only=
 return and operate on constexpr objects, but we can&#39;t pass them around=
 and maintain their &quot;constexprness&quot;.</div><div>For example here&#=
39;s a silly example:</div><div>void foo(constexpr int i) {</div><div>=C2=
=A0 =C2=A0 std::array&lt;int, i&gt; arr;</div><div>}</div><div><br></div><d=
iv>What do you think?</div></blockquote></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/550d9ed4-1484-48f2-af2b-fb5c82bfe562%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/550d9ed4-1484-48f2-af2b-fb5c82bfe562=
%40isocpp.org</a>.<br />

------=_Part_3998_574226699.1504092201211--

------=_Part_3997_1844320418.1504092201210--

.

------=_Part_1226_1058614910.1504639695532
Content-Type: multipart/alternative;
 boundary="----=_Part_1227_2089726871.1504639695533"

------=_Part_1227_2089726871.1504639695533
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One use of constexpr parameters is to better represent processor=20
intrinsics.  For example, _mm_shuffle_epi32 on x86 requires the shuffle=20
parameter to be a compile-time constant, because the constant is encoded=20
into the machine instruction.

Allowing constexpr parameters while also allowing overloading on constexpr=
=20
parameters would be very useful in situations in which a compile-time=20
implementation exists, but is less efficient if used at runtime.  A simple=
=20
example is strlen:

std::size_t strlen(constexpr const char *s)
{
    for (const char *p =3D s; ; ++p)
    {
        if (*p =3D=3D '\0')
        {
            return static_cast<std::size_t>(p - s);
        }
    }
}

std::size_t strlen(const char *s)
{
    __asm__("SSE 4.2 insanity");
}

Obviously, this isn't about strlen itself, because compilers already know=
=20
to do this for the well-known functions.

On Wednesday, August 30, 2017 at 4:23:21 AM UTC-7, mikael.p...@gmail.com=20
wrote:
>
> Id like to see it, and it would be especially great for things like=20
> allowing static_assert.=20
>
>
> Den m=C3=A5ndag 15 april 2013 kl. 18:43:21 UTC+2 skrev talz...@gmail.com:
>>
>> Hello everyone!=20
>> Lately I've been concerned with how we access tuple elements.
>> The syntax 'std::get<0>(t)' seems highly unintuitive to me.
>> What I would really like to be able to write is 't[0]'.
>> For this we need constexpr function parameters. So we can define=20
>> operator[] as follows:
>> auto operator[] (constexpr int i) -> decltype(std::get<i>(*this)) {
>>     return std::get<i>(*this);
>> }
>> (or something similar)
>>
>> I think this would help not only for tuples.
>> For example, it is not possible today to pass arbitrary constexpr object=
s=20
>> to functions because you must pass them as a template parameter.
>> Template parameters must be an int/char/typename or the like. I think=20
>> this really limits constexpr objects in terms of usability.
>>
>> As I see it, we can only return and operate on constexpr objects, but we=
=20
>> can't pass them around and maintain their "constexprness".
>> For example here's a silly example:
>> void foo(constexpr int i) {
>>     std::array<int, i> arr;
>> }
>>
>> What do you think?
>>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fa9e9250-01d2-4130-b9b7-0f0052a56f24%40isocpp.or=
g.

------=_Part_1227_2089726871.1504639695533
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One use of constexpr parameters is to better represent pro=
cessor intrinsics.=C2=A0 For example, _mm_shuffle_epi32 on x86 requires the=
 shuffle parameter to be a compile-time constant, because the constant is e=
ncoded into the machine instruction.<br><br>Allowing constexpr parameters w=
hile also allowing overloading on constexpr parameters would be very useful=
 in situations in which a compile-time implementation exists, but is less e=
fficient if used at runtime.=C2=A0 A simple example is strlen:<br><br>std::=
size_t strlen(constexpr const char *s)<br>{<br>=C2=A0=C2=A0=C2=A0 for (cons=
t char *p =3D s; ; ++p)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 if (*p =3D=3D &#39;\0&#39;)<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 return static_cast&lt;std::size_t&gt;(p - s);<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=A0 }<br>}<br><br>std=
::size_t strlen(const char *s)<br>{<br>=C2=A0=C2=A0=C2=A0 __asm__(&quot;SSE=
 4.2 insanity&quot;);<br>}<br><br>Obviously, this isn&#39;t about strlen it=
self, because compilers already know to do this for the well-known function=
s.<br><br>On Wednesday, August 30, 2017 at 4:23:21 AM UTC-7, mikael.p...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Id like to see it, and it would be especially great for things like allowi=
ng static_assert.=C2=A0<div><br><div><div><br>Den m=C3=A5ndag 15 april 2013=
 kl. 18:43:21 UTC+2 skrev <a>talz...@gmail.com</a>:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">Hello everyone!=C2=A0<div>Lately I&#39;ve been concerned wi=
th how we access tuple elements.</div><div>The syntax &#39;std::get&lt;0&gt=
;(t)&#39; seems highly unintuitive to me.<div>What I would really like to b=
e able to write is &#39;t[0]&#39;.</div></div><div>For this we need constex=
pr function parameters. So we can define operator[] as follows:</div><div>a=
uto operator[] (constexpr int i) -&gt; decltype(std::get&lt;i&gt;(*this)) {=
</div><div>=C2=A0 =C2=A0 return std::get&lt;i&gt;(*this);</div><div>}</div>=
<div>(or something similar)</div><div><br></div><div>I think this would hel=
p not only for tuples.</div><div>For example, it is not possible today to p=
ass arbitrary constexpr objects to functions because you must pass them as =
a template parameter.</div><div>Template parameters must be an int/char/typ=
ename or the like. I think this really limits constexpr objects in terms of=
 usability.</div><div><br></div><div>As I see it, we can only return and op=
erate on constexpr objects, but we can&#39;t pass them around and maintain =
their &quot;constexprness&quot;.</div><div>For example here&#39;s a silly e=
xample:</div><div>void foo(constexpr int i) {</div><div>=C2=A0 =C2=A0 std::=
array&lt;int, i&gt; arr;</div><div>}</div><div><br></div><div>What do you t=
hink?</div></blockquote></div></div></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fa9e9250-01d2-4130-b9b7-0f0052a56f24%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fa9e9250-01d2-4130-b9b7-0f0052a56f24=
%40isocpp.org</a>.<br />

------=_Part_1227_2089726871.1504639695533--

------=_Part_1226_1058614910.1504639695532--

.

------=_Part_2057_1082569484.1504690520782
Content-Type: multipart/alternative;
 boundary="----=_Part_2058_1861614333.1504690520782"

------=_Part_2058_1861614333.1504690520782
Content-Type: text/plain; charset="UTF-8"


>
>  A simple example is strlen


Nice!

Another use case would be to give std::tuple an operator[]:

template<typename... Ts>
class tuple
{
    /* ... */

    const auto& operator[]( constexpr std::size_t index ) const {
        return std::get<index>(*this);
    }
};

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffc7d3a1-ac6d-421a-a71a-ae93d90b4149%40isocpp.org.

------=_Part_2058_1861614333.1504690520782
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
=C2=A0A simple example is strlen</blockquote><div><br></div><div>Nice!=C2=
=A0</div><div><br></div>Another use case would be to give std::tuple an ope=
rator[]:<div><br></div><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">template</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">typename</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> tuple<br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">/* ... */</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[](</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t=
 index </span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">get</span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">&lt;index&gt;</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(*</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">this</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">};</span></div></code></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ffc7d3a1-ac6d-421a-a71a-ae93d90b4149%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ffc7d3a1-ac6d-421a-a71a-ae93d90b4149=
%40isocpp.org</a>.<br />

------=_Part_2058_1861614333.1504690520782--

------=_Part_2057_1082569484.1504690520782--

.

------=_Part_4388_571254948.1505772215792
Content-Type: multipart/alternative;
 boundary="----=_Part_4389_1922130848.1505772215794"

------=_Part_4389_1922130848.1505772215794
Content-Type: text/plain; charset="UTF-8"

I made an analogue proposal a while back but except for one positive
opinion it didn't garner much attention.
My proposal is a counter proposal of sort: constexpr(true) specialization.

   - A constexpr(true) being a constexpr function/method that can't
   fallback into a runtime function.
   - can only call constexpr method & functions.
   - must be requested explicitly (constexpr assign, constexpr unary
   operator).
   - cannot issue linkage (no mangling for itself nor for the types that it
   uses internally), thereby solving the issue of literal non-type template
   parameters
   - all its arguments are constexpr and usable as such.
   - A runtime and a compile-time version of a same function for more
   efficient runtime and more powerful compile-time coding.

Now here is a *detailed exemple*.

//compile-time only function
//it will never have linkage
//all its arguments are constexpr
//a non-constexpr expression usage in its definition will cause an error
instead of a fallback like normal constexpr
//is only called in an explicit constexpr context unlike normal constexpr
constexpr(true) auto func(Literal r) {}

//runtime specialization of func
/*constexpr(false)*/ auto func(Literal r) {}

//error redefinition of 'constexpr(false) void func(Literal)'
constexpr void func(Literal) {}

constexpr(true) auto func2();
//allowed
//constexpr is ignored, might warn, retains inline side effects
constexpr auto func2();

constexpr auto func3();
constexpr auto error_0 = func3();
//error: constexpr specialization of 'func3' after instanciation
constexpr(true) auto func3();

//addresses demands for partially constexpr argument-list
constexpr(true) void partial_constexpr(int constant)
{
   return [](auto&&... runtime_args) /*normal constexpr lambda*/ {
       //runtime code
       //can use 'constant' as a constexpr here without capture
   };
}

int main()
{
  constexpr auto r_0 = func(Literal{}); //constexpr(true) version called
  auto r_1 = func(Literal{}); //constexpr(false) version called

  partial_constexpr(42/*compile-time args*/)(/*runtime args*/);

  auto r_2 = constexpr func(Literal{}); //also proposed unary constexpr
operator for explicit selection, error if the expression is not constexpr
  //is equivalent to
  auto r_3 = []() { constexpr auto __ret__ = func(Literal{}); return __ret__
; }();
}

//replacing of gnu's operator"" extension
constexpr(true) auto operator""_string_literal(const char *str, size_t len)
{
    return []<size_t... Indexs>(std::index_sequence<Indexs...>&&)
    {
       return TemplateCharSeq<str[Indexs]...>{};
    }(std::make_index_sequence<len>{});
}

//operator[] for std::tuple
template <class... Args>
struct tuple
{
   ...
   constexpr(true) auto& operator[](size_t i) const
   {
      static_assert(i < sizeof...(Args));
      return std::get<i>(*this);
   }

   constexpr(true) auto& operator[](size_t i)
   {
      static_assert(i < sizeof...(Args));
      return std::get<i>(*this);
   }
   ....
};

template <class... Args> struct Select : Args... { using Args::operator
()...; };
template <class... Args> Select(Args&&...) -> Select<Args...>;

//for lambdas
void func_3()
{
  constexpr auto f_0 = []() {}; //operator() is constexpr /*fallback on
runtime*/, no changes
  constexpr auto f_1 = []() constexpr(false) {}; //operator() cannot be
called at compile-time
  constexpr auto f_2 = []() constexpr(true) {}; //operator() can only be
called a compile-time and explicitly

  constexpr Select f_3 = { f_1, f_2 };

  constexpr auto r_4 = f_3(); //f_2
  auto r_5 = f_3(); //f_1
}

Here is the summary:

- extend constexpr specifier to allow it to take a constexpr explicit bool
(not a constexpr expression unless if there are good use-cases for it)
where:

   - constexpr(false) is the default specifier of a function/method
      - optional for functions/method.
      - if specified with lambdas allows not-constexpr lambda as lambdas
      are by default constexpr.
   - constexpr(true) is a constexpr only function.
      - no Assembly representation (no linkage nor mangling).
      - all arguments are constexpr.
      - error if non-constexpr expression is used (a constexpr fallback to
      runtime because of an overflow for instance).
      - only used in explicit constexpr context.
      - cannot be called before its specialization if specialization or
      else error.
      - constexpr
      - keeps all its properties and definition.
      - will still trigger redefinition error if previous constexpr(false)
      version previously defined.
      - constexpr attribute ignored if previous constexpr(true) is defined.

- unary constexpr operator to request a constexpr expression explicitly:
   auto t = constexpr expr; //will error if expr cannot resolve into a
constexpr expression

The reason why I believe in this proposal:

   - drastically improve compile-time programming
   - no mangling issues, solves a lot of other proposal (a better
   is_constexpr, operator[] for std::tuple, getting rid of string literal gnu
   extension, etc...)
   - no new keyword.
   - zero runtime impact.
   - maintains backward compatibility.
   - gives more expressiveness for lambda


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bf21a2c1-91b7-4be1-ad5d-ab82f90f5fe2%40isocpp.org.

------=_Part_4389_1922130848.1505772215794
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I made an analogue proposal a while back but except f=
or one positive opinion it didn&#39;t garner much attention.</div>My propos=
al is a counter proposal of sort: constexpr(true) specialization.<div><ul><=
li>A constexpr(true) being a constexpr function/method that can&#39;t fallb=
ack into a runtime function.</li><li>can only call constexpr method &amp; f=
unctions.<br></li><li>must be requested explicitly (constexpr assign, const=
expr unary operator).</li><li>cannot issue linkage (no mangling for itself =
nor for the types that it uses internally), thereby solving the issue of li=
teral non-type template parameters</li><li>all its arguments are constexpr =
and usable as such.<br></li><li>A runtime and a compile-time version of a s=
ame function for more efficient runtime and more powerful compile-time codi=
ng.</li></ul>Now here is a=C2=A0<b>detailed exemple</b>.<br></div><div><div=
><br></div><div style=3D"border-width: 1px; border-style: solid; border-col=
or: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap: br=
eak-word;"><code><span style=3D"color: rgb(136, 0, 0);">//compile-time only=
 function</span><span style=3D"color: rgb(0, 0, 0);"><br></span><span style=
=3D"color: rgb(136, 0, 0);">//it will never have linkage</span><span style=
=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(136, 0, 0);"=
>//all its arguments are constexpr</span><span style=3D"color: rgb(0, 0, 0)=
;"><br></span><span style=3D"color: rgb(136, 0, 0);">//a non-constexpr expr=
ession usage in its definition will cause an error instead of a fallback li=
ke normal constexpr</span><span style=3D"color: rgb(0, 0, 0);"><br></span><=
span style=3D"color: rgb(136, 0, 0);">//is only called in an explicit const=
expr context unlike normal constexpr</span><span style=3D"color: rgb(0, 0, =
0);"><br></span><span style=3D"color: rgb(0, 0, 136);">constexpr</span><spa=
n style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0=
, 136);">true</span><span style=3D"color: rgb(102, 102, 0);">)</span><span =
style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0,=
 136);">auto</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0func</span><s=
pan style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(10=
2, 0, 102);">Literal</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0r</sp=
an><span style=3D"color: rgb(102, 102, 0);">) {}</span><span style=3D"color=
: rgb(0, 0, 0);"><br><br></span><span style=3D"color: rgb(136, 0, 0);">//ru=
ntime specialization of func</span><span style=3D"color: rgb(0, 0, 0);"><br=
></span><span style=3D"color: rgb(136, 0, 0);">/*constexpr(false)*/</span><=
span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><font color=3D"#000088">au=
to</font><span style=3D"color: rgb(0, 0, 0);">=C2=A0func</span><span style=
=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(102, 0, 102=
);">Literal</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0r</span><span =
style=3D"color: rgb(102, 102, 0);">) {}</span><span style=3D"color: rgb(0, =
0, 0);"><br><br></span><span style=3D"color: rgb(136, 0, 0);">//error redef=
inition of &#39;constexpr(false) void func(Literal)&#39;</span><span style=
=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(0, 0, 136);"=
>constexpr</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span st=
yle=3D"color: rgb(0, 0, 136);">void</span><span style=3D"color: rgb(0, 0, 0=
);">=C2=A0func</span><span style=3D"color: rgb(102, 102, 0);">(Literal) {}<=
/span><span style=3D"color: rgb(0, 0, 0);"><br><br></span><span style=3D"co=
lor: rgb(0, 0, 136);">constexpr</span><span style=3D"color: rgb(102, 102, 0=
);">(</span><span style=3D"color: rgb(0, 0, 136);">true</span><span style=
=3D"color: rgb(102, 102, 0);">)</span><span style=3D"color: rgb(0, 0, 0);">=
=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">auto</span><span style=
=3D"color: rgb(0, 0, 0);">=C2=A0func2</span><span style=3D"color: rgb(102, =
102, 0);">()</span><font color=3D"#000000"><span style=3D"color: rgb(102, 1=
02, 0);">;</span><br><span style=3D"color: rgb(136, 0, 0);">//allowed</span=
><br><span style=3D"color: rgb(136, 0, 0);">//constexpr is ignored, might w=
arn, retains inline side effects</span><br></font><span style=3D"color: rgb=
(0, 0, 136);">constexpr</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</=
span><span style=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"color=
: rgb(0, 0, 0);">=C2=A0func2</span><span style=3D"color: rgb(102, 102, 0);"=
>()</span><font color=3D"#000000"><span style=3D"color: rgb(102, 102, 0);">=
;</span><br><br><span style=3D"color: rgb(0, 0, 136);">constexpr</span>=C2=
=A0<span style=3D"color: rgb(0, 0, 136);">auto</span>=C2=A0func3<span style=
=3D"color: rgb(102, 102, 0);">();</span><br><span style=3D"color: rgb(0, 0,=
 136);">constexpr</span>=C2=A0<span style=3D"color: rgb(0, 0, 136);">auto</=
span>=C2=A0error_0=C2=A0<span style=3D"color: rgb(102, 102, 0);">=3D</span>=
=C2=A0func3<span style=3D"color: rgb(102, 102, 0);">();</span><br><span sty=
le=3D"color: rgb(136, 0, 0);">//error: constexpr specialization of &#39;fun=
c3&#39; after instanciation</span><br><span style=3D"color: rgb(0, 0, 136);=
">constexpr</span><span style=3D"color: rgb(102, 102, 0);">(</span><span st=
yle=3D"color: rgb(0, 0, 136);">true</span><span style=3D"color: rgb(102, 10=
2, 0);">)</span>=C2=A0<span style=3D"color: rgb(0, 0, 136);">auto</span>=C2=
=A0func3<span style=3D"color: rgb(102, 102, 0);">();</span></font><span sty=
le=3D"color: rgb(0, 0, 0);"><br><br></span><span style=3D"color: rgb(136, 0=
, 0);">//addresses demands for partially constexpr argument-list</span><spa=
n style=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(0, 0,=
 136);">constexpr</span><span style=3D"color: rgb(102, 102, 0);">(</span><s=
pan style=3D"color: rgb(0, 0, 136);">true</span><span style=3D"color: rgb(1=
02, 102, 0);">)</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><sp=
an style=3D"color: rgb(0, 0, 136);">void</span><span style=3D"color: rgb(0,=
 0, 0);">=C2=A0partial_constexpr</span><span style=3D"color: rgb(102, 102, =
0);">(</span><span style=3D"color: rgb(0, 0, 136);">int</span><span style=
=3D"color: rgb(0, 0, 0);">=C2=A0constant</span><span style=3D"color: rgb(10=
2, 102, 0);">)</span><span style=3D"color: rgb(0, 0, 0);"><br></span><span =
style=3D"color: rgb(102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, =
0);"><br>=C2=A0 =C2=A0</span><span style=3D"color: rgb(0, 0, 136);">return<=
/span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"colo=
r: rgb(102, 102, 0);">[](</span><span style=3D"color: rgb(0, 0, 136);">auto=
</span><span style=3D"color: rgb(102, 102, 0);">&amp;&amp;...</span><span s=
tyle=3D"color: rgb(0, 0, 0);">=C2=A0runtime_args</span><span style=3D"color=
: rgb(102, 102, 0);">) /*normal constexpr lambda*/</span><span style=3D"col=
or: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">{<=
/span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0<=
/span><span style=3D"color: rgb(136, 0, 0);">//runtime code</span><span sty=
le=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span sty=
le=3D"color: rgb(136, 0, 0);">//can use &#39;constant&#39; as a constexpr h=
ere without capture</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =
=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">};</span><span style=
=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102, 0)=
;">}</span><span style=3D"color: rgb(0, 0, 0);"><br><br></span><span style=
=3D"color: rgb(0, 0, 136);">int</span><span style=3D"color: rgb(0, 0, 0);">=
=C2=A0main</span><span style=3D"color: rgb(102, 102, 0);">()</span><span st=
yle=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102,=
 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0=C2=A0</span><=
span style=3D"color: rgb(0, 0, 136);">constexpr</span><span style=3D"color:=
 rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">auto</s=
pan><span style=3D"color: rgb(0, 0, 0);">=C2=A0r_0=C2=A0</span><span style=
=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);=
">=C2=A0func</span><span style=3D"color: rgb(102, 102, 0);">(</span><span s=
tyle=3D"color: rgb(102, 0, 102);">Literal</span><span style=3D"color: rgb(1=
02, 102, 0);">{});</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span>=
<span style=3D"color: rgb(136, 0, 0);">//constexpr(true) version called</sp=
an><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0=C2=A0</span><span style=
=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"color: rgb(0, 0, 0);"=
>=C2=A0r_1=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">=3D</span><=
span style=3D"color: rgb(0, 0, 0);">=C2=A0func</span><span style=3D"color: =
rgb(102, 102, 0);">(</span><font color=3D"#000000"><span style=3D"color: rg=
b(102, 0, 102);">Literal</span><span style=3D"color: rgb(102, 102, 0);">{})=
;</span>=C2=A0<span style=3D"color: rgb(136, 0, 0);">//constexpr(false) ver=
sion called</span><br><br></font><span style=3D"color: rgb(0, 0, 0);">=C2=
=A0 partial_constexpr</span><span style=3D"color: rgb(102, 102, 0);">(</spa=
n><span style=3D"color: rgb(0, 102, 102);">42</span><span style=3D"color: r=
gb(136, 0, 0);">/*compile-<wbr>time args*/</span><span style=3D"color: rgb(=
102, 102, 0);">)(</span><span style=3D"color: rgb(136, 0, 0);">/*runtime ar=
gs*/</span><span style=3D"color: rgb(102, 102, 0);">);</span><span style=3D=
"color: rgb(0, 0, 0);"><br><br>=C2=A0=C2=A0</span><span style=3D"color: rgb=
(0, 0, 136);">auto</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0r_2=C2=
=A0</span><span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D=
"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">=
constexpr</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0func</span><span=
 style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(102, =
0, 102);">Literal</span><span style=3D"color: rgb(102, 102, 0);">{});</span=
><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rg=
b(136, 0, 0);">//also proposed unary constexpr operator for explicit select=
ion, error if the expression is not constexpr</span><span style=3D"color: r=
gb(0, 0, 0);"><br>=C2=A0=C2=A0</span><span style=3D"color: rgb(136, 0, 0);"=
>//is equivalent to</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0=
=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">auto</span><span style=
=3D"color: rgb(0, 0, 0);">=C2=A0r_3=C2=A0</span><span style=3D"color: rgb(1=
02, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><=
span style=3D"color: rgb(102, 102, 0);">[]()</span><span style=3D"color: rg=
b(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">{</span>=
<span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb=
(0, 0, 136);">constexpr</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</=
span><span style=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"color=
: rgb(0, 0, 0);">=C2=A0__ret__=C2=A0</span><span style=3D"color: rgb(102, 1=
02, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0func</span><s=
pan style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(10=
2, 0, 102);">Literal</span><span style=3D"color: rgb(102, 102, 0);">{});</s=
pan><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color:=
 rgb(0, 0, 136);">return</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0_=
_ret__</span><span style=3D"color: rgb(102, 102, 0);">;</span><span style=
=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, =
0);">}();</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0<br></span><span=
 style=3D"color: rgb(102, 102, 0);">}</span><span style=3D"color: rgb(0, 0,=
 0);"><br><br></span><span style=3D"color: rgb(136, 0, 0);">//replacing of =
gnu&#39;s operator&quot;&quot; extension</span><span style=3D"color: rgb(0,=
 0, 0);"><br></span><span style=3D"color: rgb(0, 0, 136);">constexpr</span>=
<span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(=
0, 0, 136);">true</span><span style=3D"color: rgb(102, 102, 0);">)</span><s=
pan style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0=
, 0, 136);">auto</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><s=
pan style=3D"color: rgb(0, 0, 136);">operator</span><span style=3D"color: r=
gb(0, 136, 0);">&quot;&quot;</span><span style=3D"color: rgb(0, 0, 0);">_st=
ring_literal</span><span style=3D"color: rgb(102, 102, 0);">(</span><span s=
tyle=3D"color: rgb(0, 0, 136);">cons<wbr>t</span><span style=3D"color: rgb(=
0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">char</span><=
span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(=
102, 102, 0);">*</span><span style=3D"color: rgb(0, 0, 0);">str</span><span=
 style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0,=
 0);">=C2=A0size_t len</span><span style=3D"color: rgb(102, 102, 0);">)</sp=
an><span style=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rg=
b(102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =
=C2=A0=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">return</span><spa=
n style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102=
, 102, 0);">[]&lt;</span><span style=3D"color: rgb(0, 0, 0);">size_t</span>=
<span style=3D"color: rgb(102, 102, 0);">...</span><span style=3D"color: rg=
b(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">Indexs</=
span><span style=3D"color: rgb(102, 102, 0);">&gt;(</span><span style=3D"co=
lor: rgb(0, 0, 0);">std</span><span style=3D"color: rgb(102, 102, 0);">::</=
span><span style=3D"color: rgb(0, 0, 0);">index_sequence</span><span style=
=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(102, 0, =
102);">In<wbr>dexs</span><span style=3D"color: rgb(102, 102, 0);">...&gt;&a=
mp;&amp;)</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0=C2=
=A0</span><span style=3D"color: rgb(102, 102, 0);">{</span><span style=3D"c=
olor: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"c=
olor: rgb(0, 0, 136);">return</span><span style=3D"color: rgb(0, 0, 0);">=
=C2=A0</span><font color=3D"#660066">TemplateCharSeq</font><font color=3D"#=
666600">&lt;</font><span style=3D"color: rgb(0, 0, 0);">str</span><span sty=
le=3D"color: rgb(102, 102, 0);">[</span><span style=3D"color: rgb(102, 0, 1=
02);">Indexs</span><span style=3D"color: rgb(102, 102, 0);">]...<wbr>&gt;{}=
;</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0=C2=A0</span>=
<span style=3D"color: rgb(102, 102, 0);">}(</span><span style=3D"color: rgb=
(0, 0, 0);">std</span><span style=3D"color: rgb(102, 102, 0);">::</span><sp=
an style=3D"color: rgb(0, 0, 0);">make_index_sequence</span><span style=3D"=
color: rgb(0, 136, 0);">&lt;<wbr>len&gt;</span><span style=3D"color: rgb(10=
2, 102, 0);">{});</span><span style=3D"color: rgb(0, 0, 0);"><br></span><sp=
an style=3D"color: rgb(102, 102, 0);">}</span><span style=3D"color: rgb(0, =
0, 0);"><br><br></span><span style=3D"color: rgb(136, 0, 0);">//operator[] =
for std::tuple</span><span style=3D"color: rgb(0, 0, 0);"><br></span><span =
style=3D"color: rgb(0, 0, 136);">template</span><span style=3D"color: rgb(0=
, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span>=
<span style=3D"color: rgb(0, 0, 136);">class</span><span style=3D"color: rg=
b(102, 102, 0);">...</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</spa=
n><span style=3D"color: rgb(102, 0, 102);">Args</span><span style=3D"color:=
 rgb(102, 102, 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"><br></s=
pan><span style=3D"color: rgb(0, 0, 136);">struct</span><span style=3D"colo=
r: rgb(0, 0, 0);">=C2=A0tuple<br></span><span style=3D"color: rgb(102, 102,=
 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0</span>=
<span style=3D"color: rgb(102, 102, 0);">...</span><span style=3D"color: rg=
b(0, 0, 0);"><br>=C2=A0 =C2=A0</span><span style=3D"color: rgb(0, 0, 136);"=
>constexpr</span><span style=3D"color: rgb(102, 102, 0);">(</span><span sty=
le=3D"color: rgb(0, 0, 136);">true</span><span style=3D"color: rgb(102, 102=
, 0);">)</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span styl=
e=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"color: rgb(102, 102,=
 0);">&amp;</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span s=
tyle=3D"color: rgb(0, 0, 136);">operator</span><span style=3D"color: rgb(10=
2, 102, 0);">[](</span><span style=3D"color: rgb(0, 0, 0);">size_t i</span>=
<span style=3D"color: rgb(102, 102, 0);">)</span><span style=3D"color: rgb(=
0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">const</span>=
<span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0</span><span style=3D=
"color: rgb(102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);"><br=
>=C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">st=
atic_assert</span><span style=3D"color: rgb(102, 102, 0);">(</span><span st=
yle=3D"color: rgb(0, 0, 0);">i=C2=A0</span><span style=3D"color: rgb(102, 1=
02, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span=
 style=3D"color: rgb(0, 0, 136);">sizeof</span><span style=3D"color: rgb(10=
2, 102, 0);">...(</span><span style=3D"color: rgb(102, 0, 102);">Args</span=
><span style=3D"color: rgb(102, 102, 0);">));</span><span style=3D"color: r=
gb(0, 0, 0);"><br>=C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"color: rg=
b(0, 0, 136);">return</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0std<=
/span><span style=3D"color: rgb(102, 102, 0);">::</span><span style=3D"colo=
r: rgb(0, 0, 136);">get</span><span style=3D"color: rgb(0, 136, 0);">&lt;i&=
gt;</span><span style=3D"color: rgb(102, 102, 0);">(*</span><span style=3D"=
color: rgb(0, 0, 136);">this</span><span style=3D"color: rgb(102, 102, 0);"=
>);</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0</span><spa=
n style=3D"color: rgb(102, 102, 0);">}</span><span style=3D"color: rgb(0, 0=
, 0);"><br><br>=C2=A0 =C2=A0</span><span style=3D"color: rgb(0, 0, 136);">c=
onstexpr</span><font color=3D"#000000"><span style=3D"color: rgb(102, 102, =
0);">(</span><span style=3D"color: rgb(0, 0, 136);">true</span><span style=
=3D"color: rgb(102, 102, 0);">)</span>=C2=A0<span style=3D"color: rgb(0, 0,=
 136);">auto</span><span style=3D"color: rgb(102, 102, 0);">&amp;</span>=C2=
=A0<span style=3D"color: rgb(0, 0, 136);">operator</span><span style=3D"col=
or: rgb(102, 102, 0);">[](</span>size_t i<span style=3D"color: rgb(102, 102=
, 0);">)</span><br></font><span style=3D"color: rgb(0, 0, 0);">=C2=A0 =C2=
=A0</span><span style=3D"color: rgb(102, 102, 0);">{</span><span style=3D"c=
olor: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 =C2=A0=C2=A0</span><span style=3D"co=
lor: rgb(0, 0, 136);">static_assert</span><span style=3D"color: rgb(102, 10=
2, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">i=C2=A0</span><span st=
yle=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0,=
 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">sizeof</span><spa=
n style=3D"color: rgb(102, 102, 0);">...(</span><span style=3D"color: rgb(1=
02, 0, 102);">Args</span><span style=3D"color: rgb(102, 102, 0);">));</span=
><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0 =C2=A0=C2=A0</span>=
<span style=3D"color: rgb(0, 0, 136);">return</span><span style=3D"color: r=
gb(0, 0, 0);">=C2=A0std</span><span style=3D"color: rgb(102, 102, 0);">::</=
span><span style=3D"color: rgb(0, 0, 136);">get</span><span style=3D"color:=
 rgb(0, 136, 0);">&lt;i&gt;</span><span style=3D"color: rgb(102, 102, 0);">=
(*</span><span style=3D"color: rgb(0, 0, 136);">this</span><span style=3D"c=
olor: rgb(102, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);">=C2=
=A0=C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0</span><span style=3D"color: rgb(10=
2, 102, 0);">}</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0=
</span><span style=3D"color: rgb(102, 102, 0);">....</span><span style=3D"c=
olor: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(102, 102, 0);">};=
</span><span style=3D"color: rgb(0, 0, 0);"><br><br></span><span style=3D"c=
olor: rgb(0, 0, 136);">template</span><span style=3D"color: rgb(0, 0, 0);">=
=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span styl=
e=3D"color: rgb(0, 0, 136);">class</span><span style=3D"color: rgb(102, 102=
, 0);">...</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span st=
yle=3D"color: rgb(102, 0, 102);">Args</span><span style=3D"color: rgb(102, =
102, 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><spa=
n style=3D"color: rgb(0, 0, 136);">struct</span><span style=3D"color: rgb(0=
, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">Select</spa=
n><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><font color=3D"#666600"=
>:<span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: r=
gb(102, 0, 102);">Args</span>...<span style=3D"color: rgb(0, 0, 0);">=C2=A0=
</span>{<span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"co=
lor: rgb(0, 0, 136);">using</span><span style=3D"color: rgb(0, 0, 0);">=C2=
=A0</span><span style=3D"color: rgb(102, 0, 102);">Args</span>::<span style=
=3D"color: rgb(0, 0, 136);">operator</span>()...;<span style=3D"color: rgb(=
0, 0, 0);">=C2=A0</span>};<span style=3D"color: rgb(0, 0, 0);"><br></span><=
/font><span style=3D"color: rgb(0, 0, 136);">template</span><span style=3D"=
color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);"=
>&lt;</span><span style=3D"color: rgb(0, 0, 136);">class</span><span style=
=3D"color: rgb(102, 102, 0);">...</span><span style=3D"color: rgb(0, 0, 0);=
">=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">Args</span><span st=
yle=3D"color: rgb(102, 102, 0);">&gt;</span><span style=3D"color: rgb(0, 0,=
 0);">=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">Select</span><s=
pan style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(10=
2, 0, 102);">Args</span><span style=3D"color: rgb(102, 102, 0);">&amp;&amp;=
....)</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D=
"color: rgb(102, 102, 0);">-&gt;</span><span style=3D"color: rgb(0, 0, 0);"=
>=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">Select</span><span s=
tyle=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(102,=
 0, 102);">Args</span><span style=3D"color: rgb(102, 102, 0);">...&gt;;</sp=
an><span style=3D"color: rgb(0, 0, 0);"><br><br></span><span style=3D"color=
: rgb(136, 0, 0);">//for lambdas</span><span style=3D"color: rgb(0, 0, 0);"=
><br></span><span style=3D"color: rgb(0, 0, 136);">void</span><span style=
=3D"color: rgb(0, 0, 0);">=C2=A0func</span><font color=3D"#666600"><span st=
yle=3D"color: rgb(0, 0, 0);">_3</span>()<span style=3D"color: rgb(0, 0, 0);=
"><br></span></font><span style=3D"color: rgb(102, 102, 0);">{</span><span =
style=3D"color: rgb(0, 0, 0);"><br>=C2=A0=C2=A0</span><span style=3D"color:=
 rgb(0, 0, 136);">constexpr</span><span style=3D"color: rgb(0, 0, 0);">=C2=
=A0</span><span style=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"=
color: rgb(0, 0, 0);">=C2=A0f_0=C2=A0</span><span style=3D"color: rgb(102, =
102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span=
 style=3D"color: rgb(102, 102, 0);">[]()</span><span style=3D"color: rgb(0,=
 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">{};</span><s=
pan style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(1=
36, 0, 0);">//operator() is constexpr /*fallback on runtime*/, no changes</=
span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=A0=C2=A0</span><span styl=
e=3D"color: rgb(0, 0, 136);">constexpr</span><span style=3D"color: rgb(0, 0=
, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">auto</span><span=
 style=3D"color: rgb(0, 0, 0);">=C2=A0f_1=C2=A0</span><span style=3D"color:=
 rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</=
span><span style=3D"color: rgb(102, 102, 0);">[]()</span><span style=3D"col=
or: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">cons=
texpr</span><span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D=
"color: rgb(0, 0, 136);">false</span><span style=3D"color: rgb(102, 102, 0)=
;">)</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D=
"color: rgb(102, 102, 0);">{};</span><span style=3D"color: rgb(0, 0, 0);">=
=C2=A0</span><span style=3D"color: rgb(136, 0, 0);">//operator() cannot be =
called at compile-time</span><span style=3D"color: rgb(0, 0, 0);"><br>=C2=
=A0=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">constexpr</span><spa=
n style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, =
0, 136);">auto</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0f_2=C2=A0</=
span><font color=3D"#666600">=3D<span style=3D"color: rgb(0, 0, 0);">=C2=A0=
</span>[]()<span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D=
"color: rgb(0, 0, 136);">constexpr</span>(<span style=3D"color: rgb(0, 0, 1=
36);">true</span>)<span style=3D"color: rgb(0, 0, 0);">=C2=A0</span>{};<spa=
n style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(136=
, 0, 0);">//operator() can only be called a compile-time and explicitly</sp=
an></font><span style=3D"color: rgb(0, 0, 0);"><br><br>=C2=A0=C2=A0</span><=
span style=3D"color: rgb(0, 0, 136);">constexpr</span><span style=3D"color:=
 rgb(0, 0, 0);">=C2=A0</span><font color=3D"#000088"><span style=3D"color: =
rgb(102, 0, 102);">Select</span></font><span style=3D"color: rgb(0, 0, 0);"=
>=C2=A0f_3=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">=3D</span><=
span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(=
102, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0f_1</span=
><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb=
(0, 0, 0);">=C2=A0f_2=C2=A0</span><span style=3D"color: rgb(102, 102, 0);">=
};</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0<br><br>=C2=A0=C2=A0</s=
pan><span style=3D"color: rgb(0, 0, 136);">constexpr</span><span style=3D"c=
olor: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">au=
to</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0r_4=C2=A0</span><span s=
tyle=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0,=
 0);">=C2=A0f</span><font color=3D"#666600"><span style=3D"color: rgb(0, 0,=
 0);">_3</span>();<span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span s=
tyle=3D"color: rgb(136, 0, 0);">//f_2</span><span style=3D"color: rgb(0, 0,=
 0);"><br>=C2=A0=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">auto</s=
pan><span style=3D"color: rgb(0, 0, 0);">=C2=A0r_5=C2=A0</span>=3D<span sty=
le=3D"color: rgb(0, 0, 0);">=C2=A0f_3</span>();<span style=3D"color: rgb(0,=
 0, 0);">=C2=A0</span><span style=3D"color: rgb(136, 0, 0);">//f_1</span><s=
pan style=3D"color: rgb(0, 0, 0);"><br></span>}</font></code></div><div><br=
></div><div>Here is the summary:</div><div><br></div><div>- extend constexp=
r specifier to allow it to take a constexpr explicit bool (not a constexpr =
expression unless if there are good use-cases for it) where:</div><div><ul>=
<li>constexpr(false) is the default specifier of a function/method</li><ul>=
<li>optional for functions/method.</li><li>if specified with lambdas allows=
 not-constexpr lambda as lambdas are by default constexpr.</li></ul><li>con=
stexpr(true) is a constexpr only function.</li><ul><li>no Assembly represen=
tation (no linkage nor mangling).</li><li>all arguments are constexpr.</li>=
<li>error if non-constexpr expression is used (a constexpr fallback to runt=
ime because of an overflow for instance).</li><li>only used in explicit con=
stexpr context.</li><li>cannot be called before its specialization if speci=
alization or else error.<br></li></ul><li>constexpr</li><ul><li>keeps all i=
ts properties and definition.</li><li>will still trigger redefinition error=
 if previous constexpr(false) version previously defined.</li><li>constexpr=
 attribute ignored if previous constexpr(true) is defined.</li></ul></ul></=
div><div>- unary constexpr operator to request a constexpr expression expli=
citly:</div><div><div style=3D"border-width: 1px; border-style: solid; bord=
er-color: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wr=
ap: break-word;"><code><span style=3D"color: rgb(0, 0, 0);">=C2=A0 =C2=A0</=
span><span style=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"color=
: rgb(0, 0, 0);">=C2=A0t=C2=A0</span><span style=3D"color: rgb(102, 102, 0)=
;">=3D</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=
=3D"color: rgb(0, 0, 136);">constexpr</span><span style=3D"color: rgb(0, 0,=
 0);">=C2=A0expr</span><span style=3D"color: rgb(102, 102, 0);">;</span><sp=
an style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(13=
6, 0, 0);">//will error if expr cannot resolve into a constexpr expression<=
/span></code></div><br>The reason why I believe in this proposal:</div><div=
><ul><li>drastically improve compile-time programming</li><li>no mangling i=
ssues, solves a lot of other proposal (a better is_constexpr, operator[] fo=
r std::tuple, getting rid of string literal gnu extension, etc...)</li><li>=
no new keyword.</li><li>zero runtime impact.</li><li>maintains backward com=
patibility.</li><li>gives more expressiveness for lambda<br></li></ul></div=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bf21a2c1-91b7-4be1-ad5d-ab82f90f5fe2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bf21a2c1-91b7-4be1-ad5d-ab82f90f5fe2=
%40isocpp.org</a>.<br />

------=_Part_4389_1922130848.1505772215794--

------=_Part_4388_571254948.1505772215792--

.

------=_Part_1255_1813975589.1506330130450
Content-Type: multipart/alternative;
 boundary="----=_Part_1256_151138613.1506330130450"

------=_Part_1256_151138613.1506330130450
Content-Type: text/plain; charset="UTF-8"

Am Dienstag, 19. September 2017 00:03:35 UTC+2 schrieb bastie...@gmail.com:
>
> I made an analogue proposal a while back but except for one positive
> opinion it didn't garner much attention.
> My proposal is a counter proposal of sort: constexpr(true) specialization.
>
>    - A constexpr(true) being a constexpr function/method that can't
>    fallback into a runtime function.
>    - can only call constexpr method & functions.
>    - must be requested explicitly (constexpr assign, constexpr unary
>    operator).
>    - cannot issue linkage (no mangling for itself nor for the types that
>    it uses internally), thereby solving the issue of literal non-type template
>    parameters
>    - all its arguments are constexpr and usable as such.
>    - A runtime and a compile-time version of a same function for more
>    efficient runtime and more powerful compile-time coding
>
> Not a bad idea...
However, it does not allow someone to partially make a function constexpr.
If only the first parameter of a function needs to be constexpr, your
methodology forces them all to be constexpr. This is unneccessarily
restricted to my impression.
And furthermore I feel, the fact that function parameters have to be
constexpr in order to invoke the funciton is more obviously conveyed if the
parameters are being annotated with constexpr.
Because *that's* what is important for the user, not that the compiler
doesn't need to generate assembly for it. Does that make sense?
This keeps the thing intuitive and has the same (or even greater
opportunities as your solution since we then are able to overload on
individual parameters depending on their constexpr-ness).
That is, given compilers are allowed to deduce the neccessity of linkage
depending on whether all parameters are annotated 'constexpr'.

I still prever the annotation of parameters with 'constexpr' :|

Jakob

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/222fc0b7-fee6-4244-b652-18436173dfec%40isocpp.org.

------=_Part_1256_151138613.1506330130450
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Am Dienstag, 19. September 2017 00:03:35 UTC+2 schrieb bas=
tie...@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>I made an analogue proposal a while back but except for one positi=
ve opinion it didn&#39;t garner much attention.</div>My proposal is a count=
er proposal of sort: constexpr(true) specialization.<div><ul><li>A constexp=
r(true) being a constexpr function/method that can&#39;t fallback into a ru=
ntime function.</li><li>can only call constexpr method &amp; functions.<br>=
</li><li>must be requested explicitly (constexpr assign, constexpr unary op=
erator).</li><li>cannot issue linkage (no mangling for itself nor for the t=
ypes that it uses internally), thereby solving the issue of literal non-typ=
e template parameters</li><li>all its arguments are constexpr and usable as=
 such.<br></li><li>A runtime and a compile-time version of a same function =
for more efficient runtime and more powerful compile-time coding</li></ul><=
/div></div></blockquote><div>Not a bad idea...</div><div>However, it does n=
ot allow someone to partially make a function constexpr.</div><div>If only =
the first parameter of a function needs to be constexpr, your methodology f=
orces them all to be constexpr. This is unneccessarily restricted to my imp=
ression.</div><div>And furthermore I feel, the fact that function parameter=
s have to be constexpr in order to invoke the funciton is more obviously co=
nveyed if the parameters are being annotated with constexpr.</div><div>Beca=
use <i>that&#39;s</i> what is important for the user, not that the compiler=
 doesn&#39;t need to generate assembly for it. Does that make sense?</div><=
div>This keeps the thing intuitive and has the same (or even greater opport=
unities as your solution since we then are able to overload on individual p=
arameters depending on their constexpr-ness).</div><div>That is, given comp=
ilers are allowed to deduce the neccessity of linkage depending on whether =
all parameters are annotated &#39;constexpr&#39;.</div><div><br></div><div>=
I still prever the annotation of parameters with &#39;constexpr&#39; :|</di=
v><div><br></div><div>Jakob</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/222fc0b7-fee6-4244-b652-18436173dfec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/222fc0b7-fee6-4244-b652-18436173dfec=
%40isocpp.org</a>.<br />

------=_Part_1256_151138613.1506330130450--

------=_Part_1255_1813975589.1506330130450--

.

------=_Part_5378_503938800.1506360394539
Content-Type: multipart/alternative;
 boundary="----=_Part_5379_1250751782.1506360394540"

------=_Part_5379_1250751782.1506360394540
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lundi 25 septembre 2017 11:02:10 UTC+2, Jakob Riedle a =C3=A9crit :
>
> Not a bad idea...
> However, it does not allow someone to partially make a function constexpr=
..
> If only the first parameter of a function needs to be constexpr, your=20
> methodology forces them all to be constexpr. This is unneccessarily=20
> restricted to my impression.
>
Actually, it can emulated with the following:

constexpr(true) auto f(int const_expr)
{
    return [](auto&&... runtime_args) //normal constexpr lambda, might=20
produce linkage within the caller's context
    {=20
         //const_expr usable as a constexpr here
         //whilst runtime_args are not
         ...
    };
}


int main()
{
    int i =3D 0;
    f(42/*constexpr args here*/)(i/*runtime args here*/);
}

=20

> And furthermore I feel, the fact that function parameters have to be=20
> constexpr in order to invoke the funciton is more obviously conveyed if t=
he=20
> parameters are being annotated with constexpr.
> Because *that's* what is important for the user, not that the compiler=20
> doesn't need to generate assembly for it. Does that make sense?
> This keeps the thing intuitive and has the same (or even greater=20
> opportunities as your solution since we then are able to overload on=20
> individual parameters depending on their constexpr-ness).
> That is, given compilers are allowed to deduce the neccessity of linkage=
=20
> depending on whether all parameters are annotated 'constexpr'.
>
> I still prever the annotation of parameters with 'constexpr' :|
>
> Jakob
>

The thing is that partially constexpr arguments is just a syntax=20
alternative to generalized non-type template arguments.
template<std::string_view I> void func(int runtime);
and
void func(constexpr std::string_view i, int runtime);
only differs in calling conventions.

The proposal N3413=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html> aimed=
=20
at allowing any constexpr value to be passed as a template non-type=20
parameter, and every issues preventing this proposal are common with the=20
partial constexpr proposal.
Mainly:
- operator=3D=3D or bit-field analysis ?
- how to mangle operator=3D=3D ?
- how to mangle for all platform ?

This proposal has also a unique issue:
 How do you take the address of a partially constexpr function ?

I rather have N3413=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html>first=
=20
as it doesn't solve any of its issues.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3287b645-7355-4a40-a0b4-b79ae896bd32%40isocpp.or=
g.

------=_Part_5379_1250751782.1506360394540
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le lundi 25 septembre 2017 11:02:10 UTC+2, Jakob Riedle a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>Not a bad idea...</div><div>However, it does not allow someone to =
partially make a function constexpr.</div><div>If only the first parameter =
of a function needs to be constexpr, your methodology forces them all to be=
 constexpr. This is unneccessarily restricted to my impression.</div></div>=
</blockquote><div>Actually, it can emulated with the following:</div><div><=
br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
stexpr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">true</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" 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"> const_expr</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;&amp;...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> runtime_args</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//normal constexpr lambda, might produce li=
nkage within the caller&#39;s context</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> <br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//const_expr usable =
as a constexpr here</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">//whilst runtime_args are not</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 f</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">42</spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">/*constexpr arg=
s here*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">/*runtime args here=
*/</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code><=
/div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div>And furthermore I feel, the fact that function=
 parameters have to be constexpr in order to invoke the funciton is more ob=
viously conveyed if the parameters are being annotated with constexpr.</div=
><div>Because <i>that&#39;s</i> what is important for the user, not that th=
e compiler doesn&#39;t need to generate assembly for it. Does that make sen=
se?</div><div>This keeps the thing intuitive and has the same (or even grea=
ter opportunities as your solution since we then are able to overload on in=
dividual parameters depending on their constexpr-ness).</div><div>That is, =
given compilers are allowed to deduce the neccessity of linkage depending o=
n whether all parameters are annotated &#39;constexpr&#39;.</div><div><br><=
/div><div>I still prever the annotation of parameters with &#39;constexpr&#=
39; :|</div><div><br></div><div>Jakob</div></div></blockquote><div><br></di=
v><div>The thing is that partially constexpr arguments is just a syntax alt=
ernative to generalized non-type template arguments.</div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">string_view I</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> runtim=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
</div></code></div></div><div>and</div><div><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> func</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><font color=3D"#000088"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">string_view</span></font><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> runtime</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div><=
/code></div></div><div>only differs in calling conventions.</div><div><br><=
/div><div>The proposal <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2012/n3413.html">N3413</a>=C2=A0aimed at allowing any constexpr v=
alue to be passed as a template non-type parameter, and every issues preven=
ting this proposal are common with the partial constexpr proposal.</div><di=
v>Mainly:</div><div>- operator=3D=3D or bit-field analysis ?</div><div>- ho=
w to mangle operator=3D=3D ?</div><div>- how to mangle for all platform ?</=
div><div><br></div><div>This proposal has also a unique issue:</div><div>=
=C2=A0How do you take the address of a partially constexpr function ?</div>=
<div><br></div><div>I rather have=C2=A0<a href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2012/n3413.html">N3413 </a>first as it doesn&#39;=
t solve any of its issues.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3287b645-7355-4a40-a0b4-b79ae896bd32%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3287b645-7355-4a40-a0b4-b79ae896bd32=
%40isocpp.org</a>.<br />

------=_Part_5379_1250751782.1506360394540--

------=_Part_5378_503938800.1506360394539--

.