------=_Part_554_1441194788.1445172946182
Content-Type: multipart/alternative;
 boundary="----=_Part_555_159750473.1445172946183"

------=_Part_555_159750473.1445172946183
Content-Type: text/plain; charset=UTF-8

Hello everyone,

I started a proposal for using operator[] for std::tuple and, eventually,
replace std::get<>.

My proposal is a draft for now and lives here:

https://github.com/germandiagogomez/tup-op-brackets

Feedback is welcome.

Thanks for your time.

--

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

<div dir=3D"ltr">Hello everyone,<div><br></div><div>I started a proposal fo=
r using operator[] for std::tuple and, eventually, replace std::get&lt;&gt;=
..</div><div><br></div><div>My proposal is a draft for now and lives here:</=
div><div><br></div><div>https://github.com/germandiagogomez/tup-op-brackets=
<br></div><div><br></div><div>Feedback is welcome.</div><div><br></div><div=
>Thanks for your time.</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_555_159750473.1445172946183--
------=_Part_554_1441194788.1445172946182--

.

------=_Part_1316_719513605.1445180758743
Content-Type: multipart/alternative;
 boundary="----=_Part_1317_640736812.1445180758743"

------=_Part_1317_640736812.1445180758743
Content-Type: text/plain; charset=UTF-8

Assuming it actually works, I find your motivating example to not be very
motivational. Here is your before&after:

//Before:
f(std::get<0>(fib), std::get<1>(fib), std::get<2>(fib), std::get<3>(fib),
  std::get<4>(fib));

//Now:
f(fib[c<0>], fib[c<1>], fib[c<2>], fib[c<3>], fib[c<4>]);

This requires the creation of an ancillary type `c`, without which your
code would look like this:

//Before:
f(std::get<0>(fib), std::get<1>(fib), std::get<2>(fib), std::get<3>(fib),
  std::get<4>(fib));

//Now:
f(fib[std::integral_constant<size_t, 0>], fib[std::integral_constant<size_t,
<1>], fib[std::integral_constant<size_t, <2>], fib[std::integral_constant<
size_t, <3>], fib[std::integral_constant<size_t, <4>]);

Not so compact anymore, now is it? So, is `c` going to be part of the
standard library? If not, then everyone's going to have to declare one to
make this even usable.

And even if it is, what have you gained? Either everyone will use `std::c`,
or they'll invoke `using std::c`. Which means that the appropriate
comparison should be:

//Before:
f(get<0>(fib), get<1>(fib), get<2>(fib), get<3>(fib), get<4>(fib));

//Now:
f(fib[c<0>], fib[c<1>], fib[c<2>], fib[c<3>], fib[c<4>]);

After all, if I can do `using std::c`, I should be able to do `using
std::get` too. Indeed, the latter is rather less likely to conflict with
some local variable.

What is the advantage here? That it's a member function? Or is it the whole *two
characters* we save in typing `[c<0>]` instead of `get<0>()`?

There's not much motivating this, as far as I can see.

--

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

<div dir=3D"ltr">Assuming it actually works, I find your motivating example=
 to not be very motivational. Here is your before&amp;after:<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">//Before:</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
ib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #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">1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">fib</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> 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: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">fib</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">fib</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #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;" cla=
ss=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">fib</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//No=
w:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">fib</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">c</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;],</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> fib</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;],</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> fib</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;],</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">c</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;],</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> fib</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">c</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-by-pretti=
fy">4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;]=
);</span></div></code></div><br>This requires the creation of an ancillary =
type `c`, without which your code would look like this:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">//Before:</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fib=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span s=
tyle=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;"=
 class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">fib</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">get</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">fib</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">fib</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 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: #660;" c=
lass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">fib</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Now:=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">fib</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">integral_constant</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">size_t</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;],</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> fib</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">integral_constant</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">size_t</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
],</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fib</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">integral_constant</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">size_t</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;],</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">integral_constant</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">size_t</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;],</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">integral_constant</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">size_t</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">4</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;]);</span></div></code></div><br>Not so compact anymore=
, now is it? So, is `c` going to be part of the standard library? If not, t=
hen everyone&#39;s going to have to declare one to make this even usable.<b=
r><br>And even if it is, what have you gained? Either everyone will use `st=
d::c`, or they&#39;ll invoke `using std::c`. Which means that the appropria=
te comparison should be:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"=
styled-by-prettify">//Before:</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>f</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">fib</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: #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">1</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">fib</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-pretti=
fy">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">fib</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: #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">4</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Now:</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">fib</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">c</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"> fib</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;],</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> fib</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;],</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fib=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;],</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> fib</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">c</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
4</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><=
/div></code></div><br>After all, if I can do `using std::c`, I should be ab=
le to do `using std::get` too. Indeed, the latter is rather less likely to =
conflict with some local variable.<br><br>What is the advantage here? That =
it&#39;s a member function? Or is it the whole <i>two characters</i> we sav=
e in typing `[c&lt;0&gt;]` instead of `get&lt;0&gt;()`?<br><br>There&#39;s =
not much motivating this, as far as I can see.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1317_640736812.1445180758743--
------=_Part_1316_719513605.1445180758743--

.

--001a1140b77061500005226274fd
Content-Type: text/plain; charset=UTF-8

2015-10-18 22:05 GMT+07:00 Nicol Bolas <jmckesson@gmail.com>:

>
> What is the advantage here? That it's a member function? Or is it the
> whole *two characters* we save in typing `[c<0>]` instead of `get<0>()`?
>
> There's not much motivating this, as far as I can see.
>

One of the guidelines for C++ is to "make it easier to teach and learn".
This proposal tries to unify the interface to something
that seems more natural to anyone. I admit you must introduce more things
such as, maybe, user-defined literals.

I do think that doing this kind of polishing goes in the right direction,
the same as introducing _t aliases and _v variable templates.
Maybe this is just my opinion, but I think that this points to the same
direction: polishing.

Remember that not everyone is as used to C++ as people in this list, and
std::get is unnecesarily a different interface for indexing.
I see that as a candidate for improving.

Thanks for your feedback.

--

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

--001a1140b77061500005226274fd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2015-10-18 22:05 GMT+07:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>What is the =
advantage here? That it&#39;s a member function? Or is it the whole <i>two =
characters</i> we save in typing `[c&lt;0&gt;]` instead of `get&lt;0&gt;()`=
?<br><br>There&#39;s not much motivating this, as far as I can see.</div></=
blockquote><div><br></div><div>One of the guidelines for C++ is to &quot;ma=
ke it easier to teach and learn&quot;. This proposal tries to unify the int=
erface to something</div><div>that seems more natural to anyone. I admit yo=
u must introduce more things such as, maybe, user-defined literals.</div><d=
iv><br></div><div>I do think that doing this kind of polishing goes in the =
right direction, the same as introducing _t aliases and _v variable templat=
es.</div><div>Maybe this is just my opinion, but I think that this points t=
o the same direction: polishing.</div><div><br></div><div>Remember that not=
 everyone is as used to C++ as people in this list, and std::get is unneces=
arily a different interface for indexing.</div><div>I see that as a candida=
te for improving.</div><div><br></div><div>Thanks for your feedback.=C2=A0<=
/div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a1140b77061500005226274fd--

.

------=_Part_49_960073349.1445187915308
Content-Type: multipart/alternative;
 boundary="----=_Part_50_1826681253.1445187915308"

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



On Sunday, October 18, 2015 at 11:12:20 AM UTC-4, Germ=C3=A1n Diago wrote:
>
>
>
> 2015-10-18 22:05 GMT+07:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>>
>> What is the advantage here? That it's a member function? Or is it the=20
>> whole *two characters* we save in typing `[c<0>]` instead of `get<0>()`?
>>
>> There's not much motivating this, as far as I can see.
>>
>
> One of the guidelines for C++ is to "make it easier to teach and learn".=
=20
> This proposal tries to unify the interface to something
> that seems more natural to anyone.
>

Modern C++ tends to be moving *away* from member functions, not towards=20
them. What "seems more natural" depends entirely on what you've been=20
taught. Former Java programmers tend to see non-member functions as very=20
unnatural. C++ programmers raised on std::begin/end and so forth, are=20
likely more willing to see them as simply a part of the interface.

This will only increase with concepts and other upcoming C++ features. And=
=20
unified function syntax is on the cusp of making the distinction more or=20
less moot, allowing users to just say `t.get<0>()` (though that's in=20
jeopardy. Thanks, two-phase lookup).

I think new users would be better served by *not* being trained to think of=
=20
member functions as the only "natural" interface for a type. And `get`'s=20
design reinforces that.
=20

> Remember that not everyone is as used to C++ as people in this list, and=
=20
> std::get is unnecesarily a different interface for indexing.
> I see that as a candidate for improving.
>

Then again, people who are not "as used to C++" are probably not using=20
`tuple` at all. The primary uses for tuples are:

1) multiple return values. Not exactly common among neophytes.

2) template metaprogramming tools. Definitely not common among neophytes.

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

<br><br>On Sunday, October 18, 2015 at 11:12:20 AM UTC-4, Germ=C3=A1n Diago=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><d=
iv><br><div class=3D"gmail_quote">2015-10-18 22:05 GMT+07:00 Nicol Bolas <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"JuqpGWzVDwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">jmck...@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><br>What is the advantage here? That it&#39;s a me=
mber function? Or is it the whole <i>two characters</i> we save in typing `=
[c&lt;0&gt;]` instead of `get&lt;0&gt;()`?<br><br>There&#39;s not much moti=
vating this, as far as I can see.</div></blockquote><div><br></div><div>One=
 of the guidelines for C++ is to &quot;make it easier to teach and learn&qu=
ot;. This proposal tries to unify the interface to something</div><div>that=
 seems more natural to anyone.</div></div></div></div></blockquote><div><br=
>Modern C++ tends to be moving <i>away</i> from member functions, not towar=
ds them. What &quot;seems more natural&quot; depends entirely on what you&#=
39;ve been taught. Former Java programmers tend to see non-member functions=
 as very unnatural. C++ programmers raised on std::begin/end and so forth, =
are likely more willing to see them as simply a part of the interface.<br><=
br>This will only increase with concepts and other upcoming C++ features. A=
nd unified function syntax is on the cusp of making the distinction more or=
 less moot, allowing users to just say `t.get&lt;0&gt;()` (though that&#39;=
s in jeopardy. Thanks, two-phase lookup).<br><br>I think new users would be=
 better served by <i>not</i> being trained to think of member functions as =
the only &quot;natural&quot; interface for a type. And `get`&#39;s design r=
einforces that.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Remember that not ev=
eryone is as used to C++ as people in this list, and std::get is unnecesari=
ly a different interface for indexing.</div><div>I see that as a candidate =
for improving.</div></div></div></div></blockquote><div><br>Then again, peo=
ple who are not &quot;as used to C++&quot; are probably not using `tuple` a=
t all. The primary uses for tuples are:<br><br>1) multiple return values. N=
ot exactly common among neophytes.<br><br>2) template metaprogramming tools=
.. Definitely not common among neophytes.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_50_1826681253.1445187915308--
------=_Part_49_960073349.1445187915308--

.

------=_Part_1357_1627192379.1445190969920
Content-Type: multipart/alternative;
 boundary="----=_Part_1358_1307215958.1445190969921"

------=_Part_1358_1307215958.1445190969921
Content-Type: text/plain; charset=UTF-8

I think the reason for having a tuple-getter as a non-member function is,
that it produces less code, but I might be wrong with that.


The problem I see is, that the behaviours is utterly inconsistent with
other standard types. So you expect the operator[] to always return the
same type and you expect std::get to give different types. Not an
std::array can be used as a tuple of the same type and as an container.
Hence you have std::get to get the element and you have operator[].

Now if you want to have it consistent, you should be able to do basicly
everything with a tuple, which you could also do with a container. This can
become possible with std::variant, but for now it's not. If we have
std::variant, we could propose to make the container concept more general.

--

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

<div dir=3D"ltr">I think the reason for having a tuple-getter as a non-memb=
er function is, that it produces less code, but I might be wrong with that.=
<br><br><br>The problem I see is, that the behaviours is utterly inconsiste=
nt with other standard types. So you expect the operator[] to always return=
 the same type and you expect std::get to give different types. Not an std:=
:array can be used as a tuple of the same type and as an container. Hence y=
ou have std::get to get the element and you have operator[].<div><br></div>=
<div>Now if you want to have it consistent, you should be able to do basicl=
y everything with a tuple, which you could also do with a container. This c=
an become possible with std::variant, but for now it&#39;s not. If we have =
std::variant, we could propose to make the container concept more general.<=
/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_1358_1307215958.1445190969921--
------=_Part_1357_1627192379.1445190969920--

.

On Sunday 18 October 2015 10:05:15 Nicol Bolas wrote:
> Modern C++ tends to be moving *away* from member functions, not towards
> them

s/Modern C++/Modern Standard Library/

That is definitely not the trend in C++ other libraries.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

------=_Part_81_509927772.1445214189372
Content-Type: multipart/alternative;
 boundary="----=_Part_82_607888818.1445214189372"

------=_Part_82_607888818.1445214189372
Content-Type: text/plain; charset=UTF-8



>
> The problem I see is, that the behaviours is utterly inconsistent with
> other standard types.
>


> So you expect the operator[] to always return the same type.
>

II tend to look at this as indexing an ordered sequence. Makes sense. Why
should the type be the same?

Now if you want to have it consistent, you should be able to do basicly
> everything with a tuple, which you could also do with a container.
>

I do not pretend a tuple is a container, but, still, indexing is a minimum
expectation. I think the first thing a newcomer to C++
would expect from a tuple is to be able to index them. Are iterators even
possible? Maybe I should try some experiments,
but those would not work wwith the stl due to being heterogeneous.


>
>

--

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

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>The problem I see is, that the behaviours is utterly inconsist=
ent with other standard types. </div></blockquote><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">So you expect the ope=
rator[] to always return the same type.</div></blockquote><div>=C2=A0</div>=
<div>II tend to look at this as indexing an ordered sequence. Makes sense. =
Why should the type be the same?</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>Now if you want to have it con=
sistent, you should be able to do basicly everything with a tuple, which yo=
u could also do with a container. </div></div></blockquote><div><br></div><=
div>I do not pretend a tuple is a container, but, still, indexing is a mini=
mum expectation. I think the first thing a newcomer to C++=C2=A0</div><div>=
would expect from a tuple is to be able to index them. Are iterators even p=
ossible? Maybe I should try some experiments,</div><div>but those would not=
 work wwith the stl due to being heterogeneous.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0<br></d=
iv></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_82_607888818.1445214189372--
------=_Part_81_509927772.1445214189372--

.

------=_Part_1592_1308127726.1445216571586
Content-Type: multipart/alternative;
 boundary="----=_Part_1593_1001095.1445216571586"

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

On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wrote:
>
> The problem I see is, that the behaviours is utterly inconsistent with=20
>> other standard types.=20
>>
> =20
>
>> So you expect the operator[] to always return the same type.
>>
> =20
> II tend to look at this as indexing an ordered sequence. Makes sense. Why=
=20
> should the type be the same?
>

Because pretty much every other index-able class returns the same type from=
=20
its operator[].

Now if you want to have it consistent, you should be able to do basicly=20
>> everything with a tuple, which you could also do with a container.=20
>>
>
> I do not pretend a tuple is a container, but, still, indexing is a minimu=
m=20
> expectation.
>

A minimum expectation from whom?

If you look around, indexing is typically something you do to containers=20
(usually contiguous) or views thereof. So your argument seems=20
self-refuting: if users aren't supposed to see a tuple as a container, then=
=20
they aren't going to *expect* to be able to index it.

I think the first thing a newcomer to C++=20
> would expect from a tuple is to be able to index them.
>

A newcomer from some other language with native tuples? Possibly. But from=
=20
other near-C++ languages (like Java or C#, neither of which have []=20
indexing), or simply neophyte programmers? Their first question will be...=
=20
what's a tuple?

And from the description, I doubt they'll expect to be able to index it.

However, let's say that "a newcomer to C++" would indeed expect a tuple to=
=20
be indexable. Would they not also expect it to be indexable with an=20
*integer*, not some funny integral_constant thing? A newcomer who didn't=20
understand much about the language would be non-plussed to learn that this=
=20
simple loop isn't possible:

for(int x : irange(0, tpl.count()))
{
  auto &value =3D tpl[x];
}

They can't even do `tpl[c<x>()]`, which to a newbie makes perfect sense.=20
The compiler will give them some funny error they don't understand.

If we're going to start speculating about what newcomers would expect, I=20
think it's just as reasonable to think that, if you give them indexing,=20
they'll expect *integer* indexing. At least with `std::get`, the interface=
=20
is so different that there is less of a surprise when `get<x>` errors out.

Are iterators even possible?
>

Look at Boost.Fusion=20
<http://www.boost.org/doc/libs/1_59_0/libs/fusion/doc/html/>.

Now, those won't be STL iterators. But they serve the purpose of an=20
iterator, and they do work in (meta)algorithms.

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

<div dir=3D"ltr">On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=
=A1n Diago wrote:<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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The problem I =
see is, that the behaviours is utterly inconsistent with other standard typ=
es. </div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">So you expect the operator[] to always return the sam=
e type.</div></blockquote><div>=C2=A0</div><div>II tend to look at this as =
indexing an ordered sequence. Makes sense. Why should the type be the same?=
</div></div></blockquote><div><br>Because pretty much every other index-abl=
e class returns the same type from its operator[].<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>Now if you want to have it consistent=
, you should be able to do basicly everything with a tuple, which you could=
 also do with a container. </div></div></blockquote><div><br></div><div>I d=
o not pretend a tuple is a container, but, still, indexing is a minimum exp=
ectation.</div></div></blockquote><div><br>A minimum expectation from whom?=
<br><br>If you look around, indexing is typically something you do to conta=
iners (usually contiguous) or views thereof. So your argument seems self-re=
futing: if users aren&#39;t supposed to see a tuple as a container, then th=
ey aren&#39;t going to <i>expect</i> to be able to index it.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I think t=
he first thing a newcomer to C++=C2=A0</div><div>would expect from a tuple =
is to be able to index them.</div></div></blockquote><div><br>A newcomer fr=
om some other language with native tuples? Possibly. But from other near-C+=
+ languages (like Java or C#, neither of which have [] indexing), or simply=
 neophyte programmers? Their first question will be... what&#39;s a tuple?<=
br><br>And from the description, I doubt they&#39;ll expect to be able to i=
ndex it.<br><br>However, let&#39;s say that &quot;a newcomer to C++&quot; w=
ould indeed expect a tuple to be indexable. Would they not also expect it t=
o be indexable with an <i>integer</i>, not some funny integral_constant thi=
ng? A newcomer who didn&#39;t understand much about the language would be n=
on-plussed to learn that this simple loop isn&#39;t possible:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> irange</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tpl</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">count</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>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">value </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tpl</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span></div></code></div><br>They can&#3=
9;t even do `tpl[c&lt;x&gt;()]`, which to a newbie makes perfect sense. The=
 compiler will give them some funny error they don&#39;t understand.<br><br=
>If we&#39;re going to start speculating about what newcomers would expect,=
 I think it&#39;s just as reasonable to think that, if you give them indexi=
ng, they&#39;ll expect <i>integer</i> indexing. At least with `std::get`, t=
he interface is so different that there is less of a surprise when `get&lt;=
x&gt;` errors out.<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div>Are iterators even possible?</div></div></blockquot=
e><div><br>Look at <a href=3D"http://www.boost.org/doc/libs/1_59_0/libs/fus=
ion/doc/html/">Boost.Fusion</a>.<br><br>Now, those won&#39;t be STL iterato=
rs. But they serve the purpose of an iterator, and they do work in (meta)al=
gorithms.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1593_1001095.1445216571586--
------=_Part_1592_1308127726.1445216571586--

.

------=_Part_1849_848443644.1445219167728
Content-Type: multipart/alternative;
 boundary="----=_Part_1850_111375062.1445219167728"

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



El lunes, 19 de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas escribi=C3=B3=
:
>
> On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wrote:
>>
>> The problem I see is, that the behaviours is utterly inconsistent with=
=20
>>> other standard types.=20
>>>
>> =20
>>
>>> So you expect the operator[] to always return the same type.
>>>
>> =20
>> II tend to look at this as indexing an ordered sequence. Makes sense. Wh=
y=20
>> should the type be the same?
>>
>
> Because pretty much every other index-able class returns the same type=20
> from its operator[].=20
>

> Now if you want to have it consistent, you should be able to do basicly=
=20
>>> everything with a tuple, which you could also do with a container.=20
>>>
>>
>> I do not pretend a tuple is a container, but, still, indexing is a=20
>> minimum expectation.
>>
>
> A minimum expectation from whom?
>

Well, D can index tuples and they are the same as in C++. I do not know of=
=20
another language closest to C++ than D.
But the point is that it is easy to guess how to index a tuple. This is=20
just an opinion, maybe.
=20

>
> If you look around, indexing is typically something you do to containers=
=20
> (usually contiguous) or views thereof. So your argument seems=20
> self-refuting: if users aren't supposed to see a tuple as a container, th=
en=20
> they aren't going to *expect* to be able to index it.
>

Well, that a tuple is not a container does not mean we do not index access:=
=20
we usually refer to first element, second, third, of a sequence of ordered=
=20
types.
It is natural to map that to index, and not to a "special-case" provided=20
std::get. But this is open to opinion actually. I just see that it is one=
=20
less rule/function to remember:
want to access nth element of something? use operator[]. Want to access key=
=20
of an associative container? Use operator[] (most of the time, I know the=
=20
limitations).
=20

>
> I think the first thing a newcomer to C++=20
>> would expect from a tuple is to be able to index them.
>>
>
> A newcomer from some other language with native tuples? Possibly. But fro=
m=20
> other near-C++ languages (like Java or C#, neither of which have []=20
> indexing), or simply neophyte programmers? Their first question will be..=
..=20
> what's a tuple?
>

D has tuples with index access.
=20

>
> And from the description, I doubt they'll expect to be able to index it.
>
> However, let's say that "a newcomer to C++" would indeed expect a tuple t=
o=20
> be indexable. Would they not also expect it to be indexable with an=20
> *integer*, not some funny integral_constant thing? A newcomer who didn't=
=20
> understand much about the language would be non-plussed to learn that thi=
s=20
> simple loop isn't possible:
>
> for(int x : irange(0, tpl.count()))
> {
>   auto &value =3D tpl[x];
> }
>
> You can also do that in D and it is nice compile-time expansion. Actually=
=20
I have also been thinking of how to do this.
All of this comes from my impression that in D it is easier to write code,=
=20
especially with compile-time expansion and index for tuples and a
few other niceties. However, D is not C++ and I cannot replace it for most=
=20
uses.

=20

> They can't even do `tpl[c<x>()]`, which to a newbie makes perfect sense.=
=20
> The compiler will give them some funny error they don't understand.
>
> If we're going to start speculating about what newcomers would expect, I=
=20
> think it's just as reasonable to think that, if you give them indexing,=
=20
> they'll expect *integer* indexing. At least with `std::get`, the=20
> interface is so different that there is less of a surprise when `get<x>`=
=20
> errors out.
>

Well, go to 20 people that have used C++ only for some weeks. Ask them: how=
=20
would you access the nth element of a tuple? How many do you think would=20
say operator[],
and how many std::get (which maybe they do not even know). My bet is on=20
operator[]. And it is still integer access, just that needs compile-time=20
deduction, hence,
std::integer_constant is what we need. That is what Boost.Hana proposes,=20
and I see it reasonable and readable.
=20

>
> Are iterators even possible?
>>
>
> Look at Boost.Fusion=20
> <http://www.boost.org/doc/libs/1_59_0/libs/fusion/doc/html/>.
>
> Now, those won't be STL iterators. But they serve the purpose of an=20
> iterator, and they do work in (meta)algorithms.
>

Something to look into, thank you. :)=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/.

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

<br><br>El lunes, 19 de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas  escr=
ibi=C3=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On =
Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">The problem I see is, that the behaviours=
 is utterly inconsistent with other standard types. </div></blockquote><div=
>=C2=A0</div><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">So yo=
u expect the operator[] to always return the same type.</div></blockquote><=
div>=C2=A0</div><div>II tend to look at this as indexing an ordered sequenc=
e. Makes sense. Why should the type be the same?</div></div></blockquote><d=
iv><br>Because pretty much every other index-able class returns the same ty=
pe from its operator[].=C2=A0</div></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><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"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>Now if you want to have it consistent, you shoul=
d be able to do basicly everything with a tuple, which you could also do wi=
th a container. </div></div></blockquote><div><br></div><div>I do not prete=
nd a tuple is a container, but, still, indexing is a minimum expectation.</=
div></div></blockquote><div><br>A minimum expectation from whom?<br></div><=
/div></blockquote><div><br></div><div>Well, D can index tuples and they are=
 the same as in C++. I do not know of another language closest to C++ than =
D.</div><div>But the point is that it is easy to guess how to index a tuple=
.. This is just an opinion, maybe.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>If you look around, i=
ndexing is typically something you do to containers (usually contiguous) or=
 views thereof. So your argument seems self-refuting: if users aren&#39;t s=
upposed to see a tuple as a container, then they aren&#39;t going to <i>exp=
ect</i> to be able to index it.<br></div></div></blockquote><div><br></div>=
<div>Well, that a tuple is not a container does not mean we do not index ac=
cess: we usually refer to first element, second, third, of a sequence of or=
dered types.</div><div>It is natural to map that to index, and not to a &qu=
ot;special-case&quot; provided std::get. But this is open to opinion actual=
ly. I just see that it is one less rule/function to remember:</div><div>wan=
t to access nth element of something? use operator[]. Want to access key of=
 an associative container? Use operator[] (most of the time, I know the lim=
itations).</div><div>=C2=A0<br></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><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>I think the first thing a newcomer to C++=C2=A0</=
div><div>would expect from a tuple is to be able to index them.</div></div>=
</blockquote><div><br>A newcomer from some other language with native tuple=
s? Possibly. But from other near-C++ languages (like Java or C#, neither of=
 which have [] indexing), or simply neophyte programmers? Their first quest=
ion will be... what&#39;s a tuple?<br></div></div></blockquote><div><br></d=
iv><div>D has tuples with index access.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>And from the desc=
ription, I doubt they&#39;ll expect to be able to index it.<br><br>However,=
 let&#39;s say that &quot;a newcomer to C++&quot; would indeed expect a tup=
le to be indexable. Would they not also expect it to be indexable with an <=
i>integer</i>, not some funny integral_constant thing? A newcomer who didn&=
#39;t understand much about the language would be non-plussed to learn that=
 this simple loop isn&#39;t possible:<br><br><div 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><div><span style=3D"color:#008">for</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span=
><span style=3D"color:#000"> x </span><span style=3D"color:#660">:</span><s=
pan style=3D"color:#000"> irange</span><span style=3D"color:#660">(</span><=
span style=3D"color:#066">0</span><span style=3D"color:#660">,</span><span =
style=3D"color:#000"> tpl</span><span style=3D"color:#660">.</span><span st=
yle=3D"color:#000">count</span><span style=3D"color:#660">()))</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">auto</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span><=
span style=3D"color:#000">value </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> tpl</span><span style=3D"color:#660">[</span><=
span style=3D"color:#000">x</span><span style=3D"color:#660">];</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div><=
/code></div><br></div></div></blockquote><div>You can also do that in D and=
 it is nice compile-time expansion. Actually I have also been thinking of h=
ow to do this.</div><div>All of this comes from my impression that in D it =
is easier to write code, especially with compile-time expansion and index f=
or tuples and a</div><div>few other niceties. However, D is not C++ and I c=
annot replace it for most uses.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>They can&#39;t=
 even do `tpl[c&lt;x&gt;()]`, which to a newbie makes perfect sense. The co=
mpiler will give them some funny error they don&#39;t understand.<br><br>If=
 we&#39;re going to start speculating about what newcomers would expect, I =
think it&#39;s just as reasonable to think that, if you give them indexing,=
 they&#39;ll expect <i>integer</i> indexing. At least with `std::get`, the =
interface is so different that there is less of a surprise when `get&lt;x&g=
t;` errors out.<br></div></div></blockquote><div><br></div><div>Well, go to=
 20 people that have used C++ only for some weeks. Ask them: how would you =
access the nth element of a tuple? How many do you think would say operator=
[],</div><div>and how many std::get (which maybe they do not even know). My=
 bet is on operator[]. And it is still integer access, just that needs comp=
ile-time deduction, hence,</div><div>std::integer_constant is what we need.=
 That is what Boost.Hana proposes, and I see it reasonable and readable.</d=
iv><div>=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;"><div dir=
=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>Are iterators even possible?</div></div></blockquote><div><br>Lo=
ok at <a href=3D"http://www.boost.org/doc/libs/1_59_0/libs/fusion/doc/html/=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_59_0%2F=
libs%2Ffusion%2Fdoc%2Fhtml%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHieZtd3GQk=
6NG900Uqi9PDxBMWTw&#39;;return true;" onclick=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_59_0%2Flib=
s%2Ffusion%2Fdoc%2Fhtml%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNHieZtd3GQk6NG=
900Uqi9PDxBMWTw&#39;;return true;">Boost.Fusion</a>.<br><br>Now, those won&=
#39;t be STL iterators. But they serve the purpose of an iterator, and they=
 do work in (meta)algorithms.<br></div></div></blockquote><div><br></div><d=
iv>Something to look into, thank you. :)=C2=A0</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_1850_111375062.1445219167728--
------=_Part_1849_848443644.1445219167728--

.

19.10.2015 3:23, Germ=C3=A1n Diago:
> Are iterators
> even possible? Maybe I should try some experiments,
> but those would not work wwith the stl due to being heterogeneous.


Iterators are possible, but special ones. Boost.Fusion already=20
implements heterogeneous iterators, containers, algorithms, views, etc.
For instance:=20
http://www.boost.org/doc/libs/1_59_0/libs/fusion/doc/html/fusion/iterator/c=
oncepts/forward_iterator.html

--=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_1724_2111213594.1445220907285
Content-Type: multipart/alternative;
 boundary="----=_Part_1725_931746178.1445220907286"

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

18 2015 =D0=B3., 18:12:20 UTC+3 Germ=C3=A1n Diago:
>
>
> Remember that not everyone is as used to C++ as people in this list, and=
=20
> std::get is unnecesarily a different interface for indexing.
> I see that as a candidate for improving.
>

In my opinion, std::get is the most natural thing for this task.
We have tuple and compile-time number, and we should pass them into one=20
function somehow in order to get result. Compile-time things in C++ are=20
passed as template parameters, runtime - via "normal" parameters.=20
Non-member functions are preferred to member-functions. As the result=20
answer is:
some_function_template<index>(tup)
i.e.
get<index>(tup)

And by the way, tuples should not be very common in user code. They are=20
abused for multiple return values, but I think in such cases it is much=20
better to define just struct with good named fields. Or, if you want to do=
=20
everything "within" function definition, you could use:
auto foo()
{
    struct
    {
        int value;
        double x;
    } result =3D {1, 0.5};
    return result;
}

Or, with help of macro, it could be:
auto foo()
{
    return NEW((value, 1)(x, 0.5));
}

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

<div dir=3D"ltr">18 2015 =D0=B3., 18:12:20 UTC+3 Germ=C3=A1n Diago:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote"><div><br></div><div>Remember that not everyone is as used to C++=
 as people in this list, and std::get is unnecesarily a different interface=
 for indexing.</div><div>I see that as a candidate for improving.</div></di=
v></div></div></blockquote><div><br>In my opinion, std::get is the most nat=
ural thing for this task.<br>We have tuple and compile-time number, and we =
should pass them into one function somehow in order to get result. Compile-=
time things in C++ are passed as template parameters, runtime - via &quot;n=
ormal&quot; parameters. Non-member functions are preferred to member-functi=
ons. As the result answer is:<br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">some_function_template</span><span style=3D"color: #08=
0;" class=3D"styled-by-prettify">&lt;index&gt;</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">tup</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>i</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"co=
lor: #080;" class=3D"styled-by-prettify">&lt;index&gt;</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">tup</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div><br>And by the way, tuples=
 should not be very common in user code. They are abused for multiple retur=
n values, but I think in such cases it is much better to define just struct=
 with good named fields. Or, if you want to do everything &quot;within&quot=
; function definition, you could use:<br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</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">int</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> value</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">double</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x</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>=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-prettify=
"> result </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0.5</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> result</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">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br>Or, with help of macro, it could be:<br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=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"> NEW</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">((</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">value</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span sty=
le=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"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0.5</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1725_931746178.1445220907286--
------=_Part_1724_2111213594.1445220907285--

.

------=_Part_1641_837431110.1445225984504
Content-Type: multipart/alternative;
 boundary="----=_Part_1642_1027301967.1445225984504"

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

On Sunday, October 18, 2015 at 9:46:07 PM UTC-4, Germ=C3=A1n Diago wrote:
>
> El lunes, 19 de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas escribi=C3=
=B3:
>>
>> On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wrote=
:
>> =20
>>
> It is natural to map that to index, and not to a "special-case" provided=
=20
> std::get. But this is open to opinion actually. I just see that it is one=
=20
> less rule/function to remember:
> want to access nth element of something? use operator[]. Want to access=
=20
> key of an associative container? Use operator[] (most of the time, I know=
=20
> the limitations).
>

std::set and its variations don't overload operator[]. Neither does=20
std::list.

So it would seem that `operator[]` is not nearly as ubiquitous as you=20
claim. If a user wants the second value in a `list`, they can't use=20
`operator[]` for that.
=20

> They can't even do `tpl[c<x>()]`, which to a newbie makes perfect sense.=
=20
>> The compiler will give them some funny error they don't understand.
>>
>> If we're going to start speculating about what newcomers would expect, I=
=20
>> think it's just as reasonable to think that, if you give them indexing,=
=20
>> they'll expect *integer* indexing. At least with `std::get`, the=20
>> interface is so different that there is less of a surprise when `get<x>`=
=20
>> errors out.
>>
>
> Well, go to 20 people that have used C++ only for some weeks. Ask them:=
=20
> how would you access the nth element of a tuple? How many do you think=20
> would say operator[],
>
and how many std::get (which maybe they do not even know).
>

Neither. They'll ask what a tuple is.

My bet is on operator[].
>

You'd be wrong, because none of them even know what `operator[]` is. They=
=20
might say that you use `[]` notation, but they certainly would know nothing=
=20
of operator overloading.

So they're not going to say "use operator[]". They're going to say=20
`tuple[4]`. Which *you cannot* in your proposal. They would be no more=20
correct under your proposal than they would be under the current paradigm.

If C++ gets the ability to use regular old integer variables with tuple=20
access, I'd be more willing to see operator[] work on it. But unless=20
`operator[]` is going to behave like regular `operator[]` overloads (ie:=20
operating on seemingly runtime values), then I don't see the point. If=20
retrieving elements of a tuple has to be done using different syntax from=
=20
other types, I'd rather that the syntax be *very* different.

And it is still integer access, just that needs compile-time deduction,=20
> hence,
> std::integer_constant is what we need.
>

And you think that's a concept which C++ programmers who've been writing=20
code for "a few weeks" ought to be introduced to?

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

<div dir=3D"ltr">On Sunday, October 18, 2015 at 9:46:07 PM UTC-4, Germ=C3=
=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">El lunes, 19 =
de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas  escribi=C3=B3:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div>On Sunday, October 18, 2015 at 8:23:09 PM=
 UTC-4, Germ=C3=A1n Diago wrote:<br>=C2=A0</div></blockquote></blockquote><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div>It is natural to map that =
to index, and not to a &quot;special-case&quot; provided std::get. But this=
 is open to opinion actually. I just see that it is one less rule/function =
to remember:</div><div>want to access nth element of something? use operato=
r[]. Want to access key of an associative container? Use operator[] (most o=
f the time, I know the limitations).</div></blockquote><div><br>std::set an=
d its variations don&#39;t overload operator[]. Neither does std::list.<br>=
<br>So it would seem that `operator[]` is not nearly as ubiquitous as you c=
laim. If a user wants the second value in a `list`, they can&#39;t use `ope=
rator[]` for that.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div></div><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>They can&#39;t even do `tpl[c&lt;x&gt;()]`, which to a newbi=
e makes perfect sense. The compiler will give them some funny error they do=
n&#39;t understand.<br><br>If we&#39;re going to start speculating about wh=
at newcomers would expect, I think it&#39;s just as reasonable to think tha=
t, if you give them indexing, they&#39;ll expect <i>integer</i> indexing. A=
t least with `std::get`, the interface is so different that there is less o=
f a surprise when `get&lt;x&gt;` errors out.<br></div></div></blockquote><d=
iv><br></div><div>Well, go to 20 people that have used C++ only for some we=
eks. Ask them: how would you access the nth element of a tuple? How many do=
 you think would say operator[],</div></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div>and how many std::get (which maybe they do not ev=
en know).</div></blockquote><div><br>Neither. They&#39;ll ask what a tuple =
is.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>My bet i=
s on operator[].<br></div></blockquote><div><br>You&#39;d be wrong, because=
 none of them even know what `operator[]` is. They might say that you use `=
[]` notation, but they certainly would know nothing of operator overloading=
..<br><br>So they&#39;re not going to say &quot;use operator[]&quot;. They&#=
39;re going to say `tuple[4]`. Which <i>you cannot</i> in your proposal. Th=
ey would be no more correct under your proposal than they would be under th=
e current paradigm.<br></div><div><br>If
 C++ gets the ability to use regular old integer variables with tuple=20
access, I&#39;d be more willing to see operator[] work on it. But unless=20
`operator[]` is going to behave like regular `operator[]` overloads (ie: op=
erating=20
on seemingly runtime values), then I don&#39;t see the point. If retrieving=
 elements of a tuple has to be done using different syntax from other types=
, I&#39;d rather that the syntax be <i>very</i> different.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div>And it is still integer acce=
ss, just that needs compile-time deduction, hence,</div><div>std::integer_c=
onstant is what we need.</div></blockquote><div><br>And you think that&#39;=
s a concept which C++ programmers who&#39;ve been writing code for &quot;a =
few weeks&quot; ought to be introduced to?<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1642_1027301967.1445225984504--
------=_Part_1641_837431110.1445225984504--

.

------=_Part_1096_1828902770.1445248828073
Content-Type: multipart/alternative;
 boundary="----=_Part_1097_1613578098.1445248828073"

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

On Sunday, October 18, 2015 at 1:55:46 PM UTC+1, Germ=C3=A1n Diago wrote:
>
> Hello everyone,
>
> I started a proposal for using operator[] for std::tuple and, eventually,=
=20
> replace std::get<>.
>
> My proposal is a draft for now and lives here:
>
> https://github.com/germandiagogomez/tup-op-brackets
>
> Feedback is welcome.
>
> Thanks for your time.
>

All comments so far have been negative. I would like to speak in favor for=
=20
this proposal instead. I hate having to write std::get<N>(tuple) all the=20
time.
Just a few suggestions:

* consider having 1st, 2nd, <N>th as literals for integral types.=20
* '3rd(tuple)' should be an option.
* with dot operator overloading we could have the nice "tuple.3rd" syntax=
=20
instead (I do not think it is supported with any of the current overloading=
=20
proposals, but it would be nice to have. Aliasing 'first' and 'second' to=
=20
1st and 2nd to make tuples fully interface compatible with pairs.

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

On Sunday, October 18, 2015 at 1:55:46 PM UTC+1, Germ=C3=A1n Diago wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hello everyone,=
<div><br></div><div>I started a proposal for using operator[] for std::tupl=
e and, eventually, replace std::get&lt;&gt;.</div><div><br></div><div>My pr=
oposal is a draft for now and lives here:</div><div><br></div><div><a href=
=3D"https://github.com/germandiagogomez/tup-op-brackets" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url=
?q\75https%3A%2F%2Fgithub.com%2Fgermandiagogomez%2Ftup-op-brackets\46sa\75D=
\46sntz\0751\46usg\75AFQjCNELA37fYtN5eQgOJz4kEPnYc8y_Nw&#39;;return true;" =
onclick=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgi=
thub.com%2Fgermandiagogomez%2Ftup-op-brackets\46sa\75D\46sntz\0751\46usg\75=
AFQjCNELA37fYtN5eQgOJz4kEPnYc8y_Nw&#39;;return true;">https://github.com/<w=
br>germandiagogomez/tup-op-<wbr>brackets</a><br></div><div><br></div><div>F=
eedback is welcome.</div><div><br></div><div>Thanks for your time.</div></d=
iv></blockquote><div><br>All comments so far have been negative. I would li=
ke to speak in favor for this proposal instead. I hate having to write std:=
:get&lt;N&gt;(tuple) all the time.<br>Just a few suggestions:<br><br>* cons=
ider having 1st, 2nd, &lt;N&gt;th as literals for integral types. <br>* &#3=
9;3rd(tuple)&#39; should be an option.<br>* with dot operator overloading w=
e could have the nice &quot;tuple.3rd&quot; syntax instead (I do not think =
it is supported with any of the current overloading proposals, but it would=
 be nice to have. Aliasing &#39;first&#39; and &#39;second&#39; to 1st and =
2nd to make tuples fully interface compatible with pairs.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1097_1613578098.1445248828073--
------=_Part_1096_1828902770.1445248828073--

.

------=_Part_2537_1125780991.1445257215236
Content-Type: multipart/alternative;
 boundary="----=_Part_2538_698503491.1445257215237"

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



El lunes, 19 de octubre de 2015, 10:39:44 (UTC+7), Nicol Bolas escribi=C3=
=B3:
>
> On Sunday, October 18, 2015 at 9:46:07 PM UTC-4, Germ=C3=A1n Diago wrote:
>>
>> El lunes, 19 de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas escribi=C3=
=B3:
>>>
>>> On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wrot=
e:
>>> =20
>>>
>> It is natural to map that to index, and not to a "special-case" provided=
=20
>> std::get. But this is open to opinion actually. I just see that it is on=
e=20
>> less rule/function to remember:
>> want to access nth element of something? use operator[]. Want to access=
=20
>> key of an associative container? Use operator[] (most of the time, I kno=
w=20
>> the limitations).
>>
>
> std::set and its variations don't overload operator[]. Neither does=20
> std::list.
>

I start to find these arguments too weak. std::list has O(n) access for=20
that. std::set is not associative. std::tuple is supposed to be constant=20
time access, at least at run-time,
because everything is solved at compile-time :)
=20

>
> So it would seem that `operator[]` is not nearly as ubiquitous as you=20
> claim. If a user wants the second value in a `list`, they can't use=20
> `operator[]` for that.=20
>
=20
>
>> They can't even do `tpl[c<x>()]`, which to a newbie makes perfect sense.=
=20
>>> The compiler will give them some funny error they don't understand.
>>>
>>> If we're going to start speculating about what newcomers would expect, =
I=20
>>> think it's just as reasonable to think that, if you give them indexing,=
=20
>>> they'll expect *integer* indexing. At least with `std::get`, the=20
>>> interface is so different that there is less of a surprise when `get<x>=
`=20
>>> errors out.
>>>
>>
>>
You have to compare alternatives: operator[] vs std::get<N>. Now your=20
requirement is a *plain* integer. Just cause you said so, right? I would=20
laugh if it were funny,
but I find the operator[] interface easier to teach, and I think it should=
=20
be part of the core of a std::tuple.=20
By the way, if operator[] must be a member function, I think this is also=
=20
something that should be fixed, maybe when we get uniform call syntax.

=20

> Well, go to 20 people that have used C++ only for some weeks. Ask them:=
=20
>> how would you access the nth element of a tuple? How many do you think=
=20
>> would say operator[],
>>
> and how many std::get (which maybe they do not even know).
>>
>
> Neither. They'll ask what a tuple is.
>
> =20

> My bet is on operator[].
>>
>
> You'd be wrong, because none of them even know what `operator[]` is. They=
=20
> might say that you use `[]` notation, but they certainly would know nothi=
ng=20
> of operator overloading.
>
=20
What syntax they would look for if they have a Python background, a D=20
background, for example. Or C background. They would synthetize std::get<N>=
=20
in their heads
and guess? Or they would say: oh, this is indexing. Indexing was this []=20
thing, right? Maybe you do not find value in this, but I do find it more=20
natural and less=20
surprising to newcomers, hence, easier to teach.


> So they're not going to say "use operator[]". They're going to say=20
> `tuple[4]`. Which *you cannot* in your proposal. They would be no more=20
> correct under your proposal than they would be under the current paradigm=
..
>
> tuple[4] vs tuple[4is] --- is there really a huge difference? Is=20
std::get<> better? Why?=20

=20

> If C++ gets the ability to use regular old integer variables with tuple=
=20
> access, I'd be more willing to see operator[] work on it. But unless=20
> `operator[]` is going to behave like regular `operator[]` overloads (ie:=
=20
> operating on seemingly runtime values), then I don't see the point. If=20
> retrieving elements of a tuple has to be done using different syntax from=
=20
> other types, I'd rather that the syntax be *very* different.
>

Cannot be done, but that proposal is pretty close to that ideal and is more=
=20
uniform than having std::get<N>.
=20

>
> And it is still integer access, just that needs compile-time deduction,=
=20
>> hence,
>> std::integer_constant is what we need.
>>
>
> And you think that's a concept which C++ programmers who've been writing=
=20
> code for "a few weeks" ought to be introduced to?
>

As an alternative to what you say: Is std::get<N>(t)  template access=20
newcomer-friendly to explain? No.=20

What is easier to teach?

1. People know operator[] and they are taught about tuples. For tuples you=
=20
teach them: tuple[1is]. (Rule is: put number, add is)
OR
2. You teach them about function std::get<N>, which has a totally different=
=20
interface, and start to tell them about passing a number in between that=20
strange <> sign.

Come on, be honest, which one is easier to teach how to use? I am not=20
talking about the implementation. Both are hairy.

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

<br><br>El lunes, 19 de octubre de 2015, 10:39:44 (UTC+7), Nicol Bolas  esc=
ribi=C3=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
 Sunday, October 18, 2015 at 9:46:07 PM UTC-4, Germ=C3=A1n Diago wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">El lunes, 19 de octubre de 2015, 8:02:5=
8 (UTC+7), Nicol Bolas  escribi=C3=B3:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div>On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago =
wrote:<br>=C2=A0</div></blockquote></blockquote><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div>It is natural to map that to index, and not to a &quot;sp=
ecial-case&quot; provided std::get. But this is open to opinion actually. I=
 just see that it is one less rule/function to remember:</div><div>want to =
access nth element of something? use operator[]. Want to access key of an a=
ssociative container? Use operator[] (most of the time, I know the limitati=
ons).</div></blockquote><div><br>std::set and its variations don&#39;t over=
load operator[]. Neither does std::list.<br></div></div></blockquote><div><=
br></div><div>I start to find these arguments too weak. std::list has O(n) =
access for that. std::set is not associative. std::tuple is supposed to be =
constant time access, at least at run-time,</div><div>because everything is=
 solved at compile-time :)</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><br>So it would seem that `operato=
r[]` is not nearly as ubiquitous as you claim. If a user wants the second v=
alue in a `list`, they can&#39;t use `operator[]` for that.=C2=A0</div></di=
v></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>They ca=
n&#39;t even do `tpl[c&lt;x&gt;()]`, which to a newbie makes perfect sense.=
 The compiler will give them some funny error they don&#39;t understand.<br=
><br>If we&#39;re going to start speculating about what newcomers would exp=
ect, I think it&#39;s just as reasonable to think that, if you give them in=
dexing, they&#39;ll expect <i>integer</i> indexing. At least with `std::get=
`, the interface is so different that there is less of a surprise when `get=
&lt;x&gt;` errors out.<br></div></div></blockquote><div><br></div></blockqu=
ote></div></blockquote><div><br></div><div>You have to compare alternatives=
: operator[] vs std::get&lt;N&gt;. Now your requirement is a *plain* intege=
r. Just cause you said so, right? I would laugh if it were funny,</div><div=
>but I find the operator[] interface easier to teach, and I think it should=
 be part of the core of a std::tuple.=C2=A0</div><div>By the way, if operat=
or[] must be a member function, I think this is also something that should =
be fixed, maybe when we get uniform call syntax.</div><div><br></div><div>=
=C2=A0</div><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"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div></div><div>Well, go to 20 peopl=
e that have used C++ only for some weeks. Ask them: how would you access th=
e nth element of a tuple? How many do you think would say operator[],</div>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>and how many std:=
:get (which maybe they do not even know).</div></blockquote><div><br>Neithe=
r. They&#39;ll ask what a tuple is.<br><br></div></div></blockquote><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div>My bet is on operato=
r[].<br></div></blockquote><div><br>You&#39;d be wrong, because none of the=
m even know what `operator[]` is. They might say that you use `[]` notation=
, but they certainly would know nothing of operator overloading.<br></div><=
/div></blockquote><div>=C2=A0<br></div><div>What syntax they would look for=
 if they have a Python background, a D background, for example. Or C backgr=
ound. They would synthetize std::get&lt;N&gt; in their heads</div><div>and =
guess? Or they would say: oh, this is indexing. Indexing was this [] thing,=
 right? Maybe you do not find value in this, but I do find it more natural =
and less=C2=A0</div><div>surprising to newcomers, hence, easier to teach.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><br>So they&#39;re not going to say &quot;use operator[]&quot;. =
They&#39;re going to say `tuple[4]`. Which <i>you cannot</i> in your propos=
al. They would be no more correct under your proposal than they would be un=
der the current paradigm.<br></div><div><br></div></div></blockquote><div>t=
uple[4] vs tuple[4is] --- is there really a huge difference? Is std::get&lt=
;&gt; better? Why?=C2=A0</div><div><br></div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>If
 C++ gets the ability to use regular old integer variables with tuple=20
access, I&#39;d be more willing to see operator[] work on it. But unless=20
`operator[]` is going to behave like regular `operator[]` overloads (ie: op=
erating=20
on seemingly runtime values), then I don&#39;t see the point. If retrieving=
 elements of a tuple has to be done using different syntax from other types=
, I&#39;d rather that the syntax be <i>very</i> different.<br></div></div><=
/blockquote><div><br></div><div>Cannot be done, but that proposal is pretty=
 close to that ideal and is more uniform than having std::get&lt;N&gt;.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And it is=
 still integer access, just that needs compile-time deduction, hence,</div>=
<div>std::integer_constant is what we need.</div></blockquote><div><br>And =
you think that&#39;s a concept which C++ programmers who&#39;ve been writin=
g code for &quot;a few weeks&quot; ought to be introduced to?<br></div></di=
v></blockquote><div><br></div><div>As an alternative to what you say: Is st=
d::get&lt;N&gt;(t) =C2=A0template access newcomer-friendly to explain? No.=
=C2=A0</div><div><br></div><div>What is easier to teach?</div><div><br></di=
v><div>1. People know operator[] and they are taught about tuples. For tupl=
es you teach them: tuple[1is]. (Rule is: put number, add is)</div><div>OR</=
div><div>2. You teach them about function std::get&lt;N&gt;, which has a to=
tally different interface, and start to tell them about passing a number in=
 between that strange &lt;&gt; sign.</div><div><br></div><div>Come on, be h=
onest, which one is easier to teach how to use? I am not talking about the =
implementation. Both are hairy.</div><div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_2538_698503491.1445257215237--
------=_Part_2537_1125780991.1445257215236--

.

------=_Part_923_1674369166.1445264996830
Content-Type: multipart/alternative;
 boundary="----=_Part_924_254526572.1445264996830"

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

On Monday, October 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=A1n Diago wrote:
>
> As an alternative to what you say: Is std::get<N>(t)  template access=20
> newcomer-friendly to explain? No.=20
>
> What is easier to teach?
>
> 1. People know operator[] and they are taught about tuples. For tuples yo=
u=20
> teach them: tuple[1is]. (Rule is: put number, add is)
> OR
> 2. You teach them about function std::get<N>, which has a totally=20
> different interface, and start to tell them about passing a number in=20
> between that strange <> sign.
>
=20
If they're still thinking "that strange <> sign" in std::get<3>(), then=20
what are they going to think about something like std::tuple<int,=20
std::vector<std::string>, std::complex<double>>? If you can teach them=20
about using tuple[1is] to access the first type, it means that that they've=
=20
already been taught about "that strange <> sign", otherwise they have no=20
idea what the first type of a tuple is.

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

<div dir=3D"ltr">On Monday, October 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=
=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>As an al=
ternative to what you say: Is std::get&lt;N&gt;(t) =C2=A0template access ne=
wcomer-friendly to explain? No.=C2=A0</div><div><br></div><div>What is easi=
er to teach?</div><div><br></div><div>1. People know operator[] and they ar=
e taught about tuples. For tuples you teach them: tuple[1is]. (Rule is: put=
 number, add is)</div><div>OR</div><div>2. You teach them about function st=
d::get&lt;N&gt;, which has a totally different interface, and start to tell=
 them about passing a number in between that strange &lt;&gt; sign.</div></=
blockquote><div>=C2=A0</div><div>If they&#39;re still thinking &quot;that s=
trange &lt;&gt; sign&quot; in std::get&lt;3&gt;(), then what are they going=
 to think about something like std::tuple&lt;int, std::vector&lt;std::strin=
g&gt;, std::complex&lt;double&gt;&gt;? If you can teach them about using tu=
ple[1is] to access the first type, it means that that they&#39;ve already b=
een taught about &quot;that strange &lt;&gt; sign&quot;, otherwise they hav=
e no idea what the first type of a tuple is.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_924_254526572.1445264996830--
------=_Part_923_1674369166.1445264996830--

.

On 2015-10-18 23:39, Nicol Bolas wrote:
> If C++ gets the ability to use regular old integer variables with tuple
> access, I'd be more willing to see operator[] work on it. But unless
> `operator[]` is going to behave like regular `operator[]` overloads (ie:
> operating on seemingly runtime values), then I don't see the point.

I would remove "seemingly" from that. It ought to *work* on runtime
values, period. (That does imply that it would have to return std::any /
std::variant...)

--
Matthew

--

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

.

------=_Part_2499_934850403.1445270143191
Content-Type: multipart/alternative;
 boundary="----=_Part_2500_1661974107.1445270143192"

------=_Part_2500_1661974107.1445270143192
Content-Type: text/plain; charset=UTF-8

On Monday, October 19, 2015 at 11:39:19 AM UTC-4, Matthew Woehlke wrote:
>
> On 2015-10-18 23:39, Nicol Bolas wrote:
> > If C++ gets the ability to use regular old integer variables with tuple
> > access, I'd be more willing to see operator[] work on it. But unless
> > `operator[]` is going to behave like regular `operator[]` overloads (ie:
> > operating on seemingly runtime values), then I don't see the point.
>
> I would remove "seemingly" from that. It ought to *work* on runtime
> values, period. (That does imply that it would have to return std::any /
> std::variant...)
>

Now that? *That's* an idea.

I'd prefer `variant` over than `any` as the return type of such a function
(with the order defined as the exact order of types in the `tuple`).
Indeed, I think this should be added to `variant` proposals.

Using operator[] and a visitor to iterate over a tuple's elements at
runtime would be a very nifty thing indeed.

In fact, such a runtime operator[] would provide a good reason to provide a
static version. For the sake of orthogonality.

--

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

<div dir=3D"ltr">On Monday, October 19, 2015 at 11:39:19 AM UTC-4, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-10-18 23=
:39, Nicol Bolas wrote:
<br>&gt; If C++ gets the ability to use regular old integer variables with =
tuple=20
<br>&gt; access, I&#39;d be more willing to see operator[] work on it. But =
unless=20
<br>&gt; `operator[]` is going to behave like regular `operator[]` overload=
s (ie:=20
<br>&gt; operating on seemingly runtime values), then I don&#39;t see the p=
oint.
<br>
<br>I would remove &quot;seemingly&quot; from that. It ought to *work* on r=
untime
<br>values, period. (That does imply that it would have to return std::any =
/
<br>std::variant...)
<br></blockquote><div><br>Now that? <i>That&#39;s</i> an idea.<br><br>I&#39=
;d prefer `variant` over than `any` as the return type of such a function (=
with the order defined as the exact order of types in the `tuple`). Indeed,=
 I think this should be added to `variant` proposals.<br><br>Using operator=
[] and a visitor to iterate over a tuple&#39;s elements at runtime would be=
 a very nifty thing indeed.<br><br>In fact, such a runtime operator[] would=
 provide a good reason to provide a static version. For the sake of orthogo=
nality.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_2500_1661974107.1445270143192--
------=_Part_2499_934850403.1445270143191--

.

------=_Part_2480_1888744644.1445270175478
Content-Type: multipart/alternative;
 boundary="----=_Part_2481_1944057745.1445270175478"

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



On Monday, October 19, 2015 at 10:29:56 AM UTC-4, Greg Marr wrote:
>
> On Monday, October 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=A1n Diago wrote:
>>
>> As an alternative to what you say: Is std::get<N>(t)  template access=20
>> newcomer-friendly to explain? No.=20
>>
>> What is easier to teach?
>>
>> 1. People know operator[] and they are taught about tuples. For tuples=
=20
>> you teach them: tuple[1is]. (Rule is: put number, add is)
>> OR
>> 2. You teach them about function std::get<N>, which has a totally=20
>> different interface, and start to tell them about passing a number in=20
>> between that strange <> sign.
>>
> =20
> If they're still thinking "that strange <> sign" in std::get<3>(), then=
=20
> what are they going to think about something like std::tuple<int,=20
> std::vector<std::string>, std::complex<double>>? If you can teach them=20
> about using tuple[1is] to access the first type, it means that that they'=
ve=20
> already been taught about "that strange <> sign", otherwise they have no=
=20
> idea what the first type of a tuple is.
>

That's generally my point. Maybe if you're writing Python or D, tuples are=
=20
a week 5 lesson. But in C++, you don't touch tuples for rather longer than=
=20
that. Or at least, not seriously.

You *might* introduce them to `std::tie` for returning multiple values=20
fairly early on. But you wouldn't be showing them `get<>` for quite some=20
time.

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

<br><br>On Monday, October 19, 2015 at 10:29:56 AM UTC-4, Greg Marr wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, Oct=
ober 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=A1n Diago wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div>As an alternative to what you say: Is std::get=
&lt;N&gt;(t) =C2=A0template access newcomer-friendly to explain? No.=C2=A0<=
/div><div><br></div><div>What is easier to teach?</div><div><br></div><div>=
1. People know operator[] and they are taught about tuples. For tuples you =
teach them: tuple[1is]. (Rule is: put number, add is)</div><div>OR</div><di=
v>2. You teach them about function std::get&lt;N&gt;, which has a totally d=
ifferent interface, and start to tell them about passing a number in betwee=
n that strange &lt;&gt; sign.</div></blockquote><div>=C2=A0</div><div>If th=
ey&#39;re still thinking &quot;that strange &lt;&gt; sign&quot; in std::get=
&lt;3&gt;(), then what are they going to think about something like std::tu=
ple&lt;int, std::vector&lt;std::string&gt;, std::complex&lt;double&gt;&gt;?=
 If you can teach them about using tuple[1is] to access the first type, it =
means that that they&#39;ve already been taught about &quot;that strange &l=
t;&gt; sign&quot;, otherwise they have no idea what the first type of a tup=
le is.</div></div></blockquote><div><br>That&#39;s generally my point. Mayb=
e if you&#39;re writing Python or D, tuples are a week 5 lesson. But in C++=
, you don&#39;t touch tuples for rather longer than that. Or at least, not =
seriously.<br><br>You <i>might</i> introduce them to `std::tie` for returni=
ng multiple values fairly early on. But you wouldn&#39;t be showing them `g=
et&lt;&gt;` for quite some time.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_2481_1944057745.1445270175478--
------=_Part_2480_1888744644.1445270175478--

.

--001a1140809a90557905227739b9
Content-Type: text/plain; charset=UTF-8

+1 for op[] with variant returns in the order of the tuple. That's cool.

Can a variant store references?

Am 19.10.2015 17:55 schrieb "Nicol Bolas" <jmckesson@gmail.com>:
>
> On Monday, October 19, 2015 at 11:39:19 AM UTC-4, Matthew Woehlke wrote:
>>
>> On 2015-10-18 23:39, Nicol Bolas wrote:
>> > If C++ gets the ability to use regular old integer variables with
tuple
>> > access, I'd be more willing to see operator[] work on it. But unless
>> > `operator[]` is going to behave like regular `operator[]` overloads
(ie:
>> > operating on seemingly runtime values), then I don't see the point.
>>
>> I would remove "seemingly" from that. It ought to *work* on runtime
>> values, period. (That does imply that it would have to return std::any /
>> std::variant...)
>
>
> Now that? That's an idea.
>
> I'd prefer `variant` over than `any` as the return type of such a
function (with the order defined as the exact order of types in the
`tuple`). Indeed, I think this should be added to `variant` proposals.
>
> Using operator[] and a visitor to iterate over a tuple's elements at
runtime would be a very nifty thing indeed.
>
> In fact, such a runtime operator[] would provide a good reason to provide
a static version. For the sake of orthogonality.
>
> --
>
> ---
> 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/.

--

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

--001a1140809a90557905227739b9
Content-Type: text/html; charset=UTF-8

<p dir="ltr">+1 for op[] with variant returns in the order of the tuple. That&#39;s cool. </p>
<p dir="ltr">Can a variant store references?</p>
<p dir="ltr">Am 19.10.2015 17:55 schrieb &quot;Nicol Bolas&quot; &lt;<a href="mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; On Monday, October 19, 2015 at 11:39:19 AM UTC-4, Matthew Woehlke wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 2015-10-18 23:39, Nicol Bolas wrote: <br>
&gt;&gt; &gt; If C++ gets the ability to use regular old integer variables with tuple <br>
&gt;&gt; &gt; access, I&#39;d be more willing to see operator[] work on it. But unless <br>
&gt;&gt; &gt; `operator[]` is going to behave like regular `operator[]` overloads (ie: <br>
&gt;&gt; &gt; operating on seemingly runtime values), then I don&#39;t see the point. <br>
&gt;&gt;<br>
&gt;&gt; I would remove &quot;seemingly&quot; from that. It ought to *work* on runtime <br>
&gt;&gt; values, period. (That does imply that it would have to return std::any / <br>
&gt;&gt; std::variant...) <br>
&gt;<br>
&gt;<br>
&gt; Now that? That&#39;s an idea.<br>
&gt;<br>
&gt; I&#39;d prefer `variant` over than `any` as the return type of such a function (with the order defined as the exact order of types in the `tuple`). Indeed, I think this should be added to `variant` proposals.<br>
&gt;<br>
&gt; Using operator[] and a visitor to iterate over a tuple&#39;s elements at runtime would be a very nifty thing indeed.<br>
&gt;<br>
&gt; In fact, such a runtime operator[] would provide a good reason to provide a static version. For the sake of orthogonality.<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="mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</p>

<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--001a1140809a90557905227739b9--

.

------=_Part_342_469955490.1445270979887
Content-Type: multipart/alternative;
 boundary="----=_Part_343_1675117767.1445270979888"

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

On Monday, October 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=A1n Diago wrote:
>
> El lunes, 19 de octubre de 2015, 10:39:44 (UTC+7), Nicol Bolas escribi=C3=
=B3:
>>
>> On Sunday, October 18, 2015 at 9:46:07 PM UTC-4, Germ=C3=A1n Diago wrote=
:
>>>
>>> El lunes, 19 de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas escribi=
=C3=B3:
>>>>
>>>> On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wro=
te:
>>>> =20
>>>>
>>> It is natural to map that to index, and not to a "special-case" provide=
d=20
>>> std::get. But this is open to opinion actually. I just see that it is o=
ne=20
>>> less rule/function to remember:
>>> want to access nth element of something? use operator[]. Want to access=
=20
>>> key of an associative container? Use operator[] (most of the time, I kn=
ow=20
>>> the limitations).
>>>
>>
>> std::set and its variations don't overload operator[]. Neither does=20
>> std::list.
>>
>
> I start to find these arguments too weak. std::list has O(n) access for=
=20
> that. std::set is not associative.
>

The C++ standard disagrees with you. 23.4 is called "Associative=20
containers". And it contains `set`. The concept for "associative container=
=20
<http://en.cppreference.com/w/cpp/concept/AssociativeContainer>" is filled=
=20
by `set`.

Ergo `set` is an associative container. And it has no operator[]. Thus,=20
your statement that you use operator[] on associative containers is wrong.
=20

> They can't even do `tpl[c<x>()]`, which to a newbie makes perfect sense.=
=20
>>>> The compiler will give them some funny error they don't understand.
>>>>
>>>> If we're going to start speculating about what newcomers would expect,=
=20
>>>> I think it's just as reasonable to think that, if you give them indexi=
ng,=20
>>>> they'll expect *integer* indexing. At least with `std::get`, the=20
>>>> interface is so different that there is less of a surprise when `get<x=
>`=20
>>>> errors out.
>>>>
>>>
>>>
> You have to compare alternatives: operator[] vs std::get<N>. Now your=20
> requirement is a *plain* integer. Just cause you said so, right?
>

You provide no evidence for your claim that operator[] is easier to teach.=
=20
So I see no problem making unsupported claims of my own that such people=20
would expect to use an integer variable in [].

So they're not going to say "use operator[]". They're going to say=20
>> `tuple[4]`. Which *you cannot* in your proposal. They would be no more=
=20
>> correct under your proposal than they would be under the current paradig=
m.
>>
>> tuple[4] vs tuple[4is] --- is there really a huge difference?
>

Yes. At the very least, 4is requires importing the namespace that includes=
=20
the "is" literal. Not to mention, you're arguing "teachability". Well, they=
=20
have to learn to import that namespace and use the `is` suffix. And to=20
always use literals.

That's a pretty big difference from `tuple[4]`.
=20

> Is std::get<> better? Why?
>

I never claimed it was necessarily "better".

Look, if this were 2009 and we were debating including tuple in the=20
standard, I might agree with your position. However, this is 2015. Tuple is=
=20
done, there, and has been for 4 years.

To add a new interface to do the same thing, *now*? All for supposed=20
"teachability"? No. You're going to need more of a motivation than that to=
=20
add a redundant interface.
=20

> And it is still integer access, just that needs compile-time deduction,=
=20
>>> hence,
>>> std::integer_constant is what we need.
>>>
>>
>> And you think that's a concept which C++ programmers who've been writing=
=20
>> code for "a few weeks" ought to be introduced to?
>>
>
> As an alternative to what you say: Is std::get<N>(t)  template access=20
> newcomer-friendly to explain? No.=20
>
> What is easier to teach?
>
> 1. People know operator[] and they are taught about tuples. For tuples yo=
u=20
> teach them: tuple[1is]. (Rule is: put number, add is)
>

Don't forget the `using namespace` you need to use that literal.
=20

> OR
> 2. You teach them about function std::get<N>, which has a totally=20
> different interface, and start to tell them about passing a number in=20
> between that strange <> sign.
>

Others have pointed out that the whole "strange <> sign" is fundamentally=
=20
wrong, since they have to have seen that already.

To me, neither is more "teachable" than the other. `tuple` is just not a=20
newbie-programmer type.

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

On Monday, October 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=A1n Diago wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">El lunes, 19 de octubre de 2015,=
 10:39:44 (UTC+7), Nicol Bolas  escribi=C3=B3:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">On Sunday, October 18, 2015 at 9:46:07 PM UTC-4=
, Germ=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">El lunes,=
 19 de octubre de 2015, 8:02:58 (UTC+7), Nicol Bolas  escribi=C3=B3:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div>On Sunday, October 18, 2015 at 8:23:0=
9 PM UTC-4, Germ=C3=A1n Diago wrote:<br>=C2=A0</div></blockquote></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>It is natural to map that t=
o index, and not to a &quot;special-case&quot; provided std::get. But this =
is open to opinion actually. I just see that it is one less rule/function t=
o remember:</div><div>want to access nth element of something? use operator=
[]. Want to access key of an associative container? Use operator[] (most of=
 the time, I know the limitations).</div></blockquote><div><br>std::set and=
 its variations don&#39;t overload operator[]. Neither does std::list.<br><=
/div></div></blockquote><div><br></div><div>I start to find these arguments=
 too weak. std::list has O(n) access for that. std::set is not associative.=
</div></blockquote><div><br>The C++ standard disagrees with you. 23.4 is ca=
lled &quot;Associative containers&quot;. And it contains `set`. The concept=
 for &quot;<a href=3D"http://en.cppreference.com/w/cpp/concept/AssociativeC=
ontainer">associative container</a>&quot; is filled by `set`.<br><br>Ergo `=
set` is an associative container. And it has no operator[]. Thus, your stat=
ement that you use operator[] on associative containers is wrong.<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div></div><div></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>They can&#39;t even do `tpl[c&lt;x&gt;()]`, which to a ne=
wbie makes perfect sense. The compiler will give them some funny error they=
 don&#39;t understand.<br><br>If we&#39;re going to start speculating about=
 what newcomers would expect, I think it&#39;s just as reasonable to think =
that, if you give them indexing, they&#39;ll expect <i>integer</i> indexing=
.. At least with `std::get`, the interface is so different that there is les=
s of a surprise when `get&lt;x&gt;` errors out.<br></div></div></blockquote=
><div><br></div></blockquote></div></blockquote><div><br></div><div>You hav=
e to compare alternatives: operator[] vs std::get&lt;N&gt;. Now your requir=
ement is a *plain* integer. Just cause you said so, right?</div></blockquot=
e><div><br>You provide no evidence for your claim that operator[] is easier=
 to teach. So I see no problem making unsupported claims of my own that suc=
h people would expect to use an integer variable in [].<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div></div><div></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>So they&#39;re not going to=
 say &quot;use operator[]&quot;. They&#39;re going to say `tuple[4]`. Which=
 <i>you cannot</i> in your proposal. They would be no more correct under yo=
ur proposal than they would be under the current paradigm.<br></div><div><b=
r></div></div></blockquote><div>tuple[4] vs tuple[4is] --- is there really =
a huge difference?</div></blockquote><div><br>Yes. At the very least, 4is r=
equires importing the namespace that includes the &quot;is&quot; literal. N=
ot to mention, you&#39;re arguing &quot;teachability&quot;. Well, they have=
 to learn to import that namespace and use the `is` suffix. And to always u=
se literals.<br><br>That&#39;s a pretty big difference from `tuple[4]`.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Is std::get&l=
t;&gt; better? Why?</div></blockquote><div><br>I never claimed it was neces=
sarily &quot;better&quot;.<br><br>Look, if this were 2009 and we were debat=
ing including tuple in the standard, I might agree with your position. Howe=
ver, this is 2015. Tuple is done, there, and has been for 4 years.<br><br>T=
o add a new interface to do the same thing, <i>now</i>? All for supposed &q=
uot;teachability&quot;? No. You&#39;re going to need more of a motivation t=
han that to add a redundant interface.<br>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div></div><div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div>And it is still integer access, just that needs compile-time deduc=
tion, hence,</div><div>std::integer_constant is what we need.</div></blockq=
uote><div><br>And you think that&#39;s a concept which C++ programmers who&=
#39;ve been writing code for &quot;a few weeks&quot; ought to be introduced=
 to?<br></div></div></blockquote><div><br></div><div>As an alternative to w=
hat you say: Is std::get&lt;N&gt;(t) =C2=A0template access newcomer-friendl=
y to explain? No.=C2=A0</div><div><br></div><div>What is easier to teach?</=
div><div><br></div><div>1. People know operator[] and they are taught about=
 tuples. For tuples you teach them: tuple[1is]. (Rule is: put number, add i=
s)</div></blockquote><div><br>Don&#39;t forget the `using namespace` you ne=
ed to use that literal.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div>OR</div><div>2. You teach them about function std::get&lt=
;N&gt;, which has a totally different interface, and start to tell them abo=
ut passing a number in between that strange &lt;&gt; sign.</div></blockquot=
e><div><br>Others have pointed out that the whole &quot;strange &lt;&gt; si=
gn&quot; is fundamentally wrong, since they have to have seen that already.=
<br><br>To me, neither is more &quot;teachable&quot; than the other. `tuple=
` is just not a newbie-programmer type.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_343_1675117767.1445270979888--
------=_Part_342_469955490.1445270979887--

.

------=_Part_2524_1723817282.1445271558601
Content-Type: multipart/alternative;
 boundary="----=_Part_2525_1978106543.1445271558601"

------=_Part_2525_1978106543.1445271558601
Content-Type: text/plain; charset=UTF-8

On Monday, October 19, 2015 at 11:59:08 AM UTC-4, Johannes Schaub wrote:
>
> +1 for op[] with variant returns in the order of the tuple. That's cool.
>
> Can a variant store references?
>

N4542 says that it can. But you can't assign to a reference, you can only
initialize to it. Which should be sufficient. As long as the reference
doesn't inhibit copy/movement, it ought to be fine.

--

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

<div dir=3D"ltr">On Monday, October 19, 2015 at 11:59:08 AM UTC-4, Johannes=
 Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">+=
1 for op[] with variant returns in the order of the tuple. That&#39;s cool.=
 </p>
<p dir=3D"ltr">Can a variant store references?</p></blockquote><div><br>N45=
42 says that it can. But you can&#39;t assign to a reference, you can only =
initialize to it. Which should be sufficient. As long as the reference does=
n&#39;t inhibit copy/movement, it ought to be fine.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_2525_1978106543.1445271558601--
------=_Part_2524_1723817282.1445271558601--

.

--001a11c01300f7cbdb0522778a06
Content-Type: text/plain; charset=UTF-8

On 19 October 2015 at 10:59, 'Johannes Schaub' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> +1 for op[] with variant returns in the order of the tuple. That's cool.
>
I must be missing the point of doing this.  Why would I want to copy each
of the members out of the tuple into a variant, as opposed to just having a
visitor visit every element in the tuple?

Can a variant store references?


Maybe we'll find out this week... :-)
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--001a11c01300f7cbdb0522778a06
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 19 October 2015 at 10:59, &#=
39;Johannes Schaub&#39; via ISO C++ Standard - Future Proposals <span dir=
=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">=
std-proposals@isocpp.org</a>&gt;</span> wrote:<br><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><p dir=3D"ltr">+1 for op[] with variant returns in the o=
rder of the tuple. That&#39;s cool.</p></blockquote></div>I must be missing=
 the point of doing this.=C2=A0 Why would I want to copy each of the member=
s out of the tuple into a variant, as opposed to just having a visitor visi=
t every element in the tuple?</div><div class=3D"gmail_extra"><br></div><di=
v class=3D"gmail_extra"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><span style=3D"font-size:13px">Can=
 a variant store references?</span></blockquote><div><br></div><div>Maybe w=
e&#39;ll find out this week... :-)=C2=A0</div>-- <br><div class=3D"gmail_si=
gnature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mail=
to:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a11c01300f7cbdb0522778a06--

.

On 2015-10-19 12:09, Nicol Bolas wrote:
> On Monday, October 19, 2015 at 8:20:15 AM UTC-4, Germ=C3=A1n Diago wrote:
>> I start to find these arguments too weak. std::list has O(n) access for=
=20
>> that. std::set is not associative.
>=20
> The C++ standard disagrees with you. 23.4 is called "Associative=20
> containers". And it contains `set`. The concept for "associative containe=
r=20
> <http://en.cppreference.com/w/cpp/concept/AssociativeContainer>" is fille=
d=20
> by `set`.
>=20
> Ergo `set` is an associative container. And it has no operator[]. Thus,=
=20
> your statement that you use operator[] on associative containers is wrong=
..

std::set is... weird. It is an associative container that has keys, but
no values. There is no more technical reason for it to omit operator[]
than for std::map to omit operator[]. More likely, the reason it has no
operator[] is because a) it would be redundant with the insert() method,
and b) it would not return a value, which would be very peculiar for an
operator[].

The reason for std::tuple to not have an operator[] is not entirely
dissimilar; the return value is necessarily exotic in some fashion.
Either it is a "strange" type (std::any or std::variant), or it is
highly sensitive to overload resolution (which, as with having no return
value at all, would be novel for an operator[]).

(The first of those I can see being overcome by the utility of being
able to index a tuple with a runtime index. The second is distinctly
lacking in meaningful advantage.)

--=20
Matthew

--=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_188_1103779251.1446821123938
Content-Type: multipart/alternative;
 boundary="----=_Part_189_1739814530.1446821123939"

------=_Part_189_1739814530.1446821123939
Content-Type: text/plain; charset=UTF-8

Is there any problem with writing it this way?

auto operator[]( constexpr int idx ) -> decltype(std::tuple_element<idx,T>::
type){
 return std::get<idx>(*this);
}

I hope I did not miss some part of the conversation that said something
about this solution.
Yours,
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Is there any problem with writing it this way?<div><br></d=
iv><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">operator</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">[](</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
stexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> idx </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tuple_el=
ement</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">idx</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">type</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</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">get</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;=
idx&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"styled-by-prettify">);</span><span st=
yle=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>I hope I did not miss some part of the conversation that sa=
id something about this solution.</div><div>Yours,</div><div>Jakob</div></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_189_1739814530.1446821123939--
------=_Part_188_1103779251.1446821123938--

.

--001a11401b1a2e21aa0523e1b7bc
Content-Type: text/plain; charset=UTF-8

On 6 November 2015 at 14:45, Jakob Riedle <jakob.riedle@gmail.com> wrote:

> Is there any problem with writing it this way?
>
> auto operator[]( constexpr int idx ) -> decltype(std::tuple_element<idx,T
> >::type){
>  return std::get<idx>(*this);
> }
>
> I hope I did not miss some part of the conversation that said something
> about this solution.
> Yours,
> Jakob
>

won't compile as you can't have constexpr parameters. it's explained well
here:
http://boostorg.github.io/hana/index.html#tutorial-appendix-constexpr

hana also has an implementation of the [] operator for tuple's that does
work which is very similar to yours:

  template <typename N>
  constexpr decltype(auto) operator[](N const&) {
     return std::get<N::value>(*this);
  }

taken from here:
http://boostorg.github.io/hana/index.html#tutorial-integral-more

--

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

--001a11401b1a2e21aa0523e1b7bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 6 November 2015 at 14:45, Jakob Riedle <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jakob.riedle@gmail.com" target=3D"_blank">jakob.riedle@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr">Is there any problem with writing it this way?<div><br></=
div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,13=
6)">auto</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"colo=
r:rgb(0,0,136)">operator</span><span style=3D"color:rgb(102,102,0)">[](</sp=
an><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,13=
6)">constexpr</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> idx </span=
><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(102,102,0)">-&gt;</span><span style=3D=
"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">decltype</spa=
n><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><span style=3D=
"color:rgb(0,0,0)">tuple_element</span><span style=3D"color:rgb(102,102,0)"=
>&lt;</span><span style=3D"color:rgb(0,0,0)">idx</span><span style=3D"color=
:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)">T</span><span sty=
le=3D"color:rgb(102,102,0)">&gt;::</span><span style=3D"color:rgb(0,0,0)">t=
ype</span><span style=3D"color:rgb(102,102,0)">){</span><span style=3D"colo=
r:rgb(0,0,0)"><br>=C2=A0</span><span style=3D"color:rgb(0,0,136)">return</s=
pan><span style=3D"color:rgb(0,0,0)"> std</span><span style=3D"color:rgb(10=
2,102,0)">::</span><span style=3D"color:rgb(0,0,136)">get</span><span style=
=3D"color:rgb(0,136,0)">&lt;idx&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)"><br></span><=
span style=3D"color:rgb(102,102,0)">}</span></div></code></div><div><br></d=
iv><div>I hope I did not miss some part of the conversation that said somet=
hing about this solution.</div><div>Yours,</div><div>Jakob</div></div></blo=
ckquote><div><br></div><div>won&#39;t compile as you can&#39;t have constex=
pr parameters. it&#39;s explained well here:<br><a href=3D"http://boostorg.=
github.io/hana/index.html#tutorial-appendix-constexpr">http://boostorg.gith=
ub.io/hana/index.html#tutorial-appendix-constexpr</a><br><br></div><div>han=
a also has an implementation of the [] operator for tuple&#39;s that does w=
ork which is very similar to yours:<br><br><div class=3D""><div class=3D"">=
<span class=3D"">=C2=A0 template</span> &lt;<span class=3D"">typename</span=
> N&gt;</div>
<div class=3D"">=C2=A0 constexpr decltype(<span class=3D"">auto</span>) ope=
rator[](N const&amp;) {</div>
<div class=3D"">=C2=A0=C2=A0=C2=A0=C2=A0  <span class=3D"">return</span> st=
d::get&lt;N::value&gt;(*this);</div>
<div class=3D"">=C2=A0 }</div>
</div>=C2=A0<br>taken from here: <a href=3D"http://boostorg.github.io/hana/=
index.html#tutorial-integral-more">http://boostorg.github.io/hana/index.htm=
l#tutorial-integral-more</a><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a11401b1a2e21aa0523e1b7bc--

.

Le 19/10/15 12:00, Giovanni Piero Deretta a =C3=A9crit :
> On Sunday, October 18, 2015 at 1:55:46 PM UTC+1, Germ=C3=A1n Diago wrote:
>> Hello everyone,
>>
>> I started a proposal for using operator[] for std::tuple and, eventually=
,
>> replace std::get<>.
>>
>> My proposal is a draft for now and lives here:
>>
>> https://github.com/germandiagogomez/tup-op-brackets
>>
>> Feedback is welcome.
>>
>> Thanks for your time.
>>
> All comments so far have been negative.
As often, isn't it?
> I would like to speak in favor for
> this proposal instead. I hate having to write std::get<N>(tuple) all the
> time.
> Just a few suggestions:
>
> * consider having 1st, 2nd, <N>th as literals for integral types.
+1
> * '3rd(tuple)' should be an option.
So the 3rd should be a function object isn't it?

* tuple[3rd] is already quite readable.
> * with dot operator overloading we could have the nice "tuple.3rd" syntax
> instead (I do not think it is supported with any of the current overloadi=
ng
> proposals, but it would be nice to have. Aliasing 'first' and 'second' to
> 1st and 2nd to make tuples fully interface compatible with pairs.
>
Well, we don't have them yet. Maybe this will add some ambiguity. Let=20
see when the proposal will be there.

Vicente

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

.

Le 19/10/15 17:59, 'Johannes Schaub' via ISO C++ Standard - Future=20
Proposals a =C3=A9crit :
> +1 for op[] with variant returns in the order of the tuple. That's cool.
The access must return a reference as get does. You can always store it=20
in a variant if you want.

Vicente

--=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_1384_924867365.1446842190967
Content-Type: multipart/alternative;
 boundary="----=_Part_1385_706730675.1446842190968"

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

On Sunday, October 18, 2015 at 7:02:58 PM UTC-6, Nicol Bolas wrote:On=20
Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago wrote:
>
> The problem I see is, that the behaviours is utterly inconsistent with=20
>> other standard types.=20
>>
> =20
>
>> So you expect the operator[] to always return the same type.
>>
> =20
>  II tend to look at this as indexing an ordered sequence. Makes sense. Wh=
y=20
> should the type be the same?
>
> Because pretty much every other index-able class returns the same type=20
> from its operator[].
>

Tuple is a unique and recent feature that is rather different from most=20
existing features. The closest pre-existing features are std::pair and=20
structs. There's nothing strange about equipping pairs with these=20
operators, that'd be rather useful actually. On the other hand iterating=20
through a struct would be quite a hassle. Especially, operator-based=20
element access for tuple values is natural given the role tuples fill in a=
=20
language that already had pair<int,pair<int,..>> and structs.

A minimum expectation from whom?
> ...
>

>> I think the first thing a newcomer to C++=20
>> would expect from a tuple is to be able to index them.
>>
>
> A newcomer from some other language with native tuples? Possibly. But fro=
m=20
> other near-C++ languages (like Java or C#, neither of which have []=20
> indexing), or simply neophyte programmers? Their first question will be..=
..=20
> what's a tuple?
>
> And from the description, I doubt they'll expect to be able to index it.
>

Tuples were brought in to fill blanks common to many higher level=20
languages. The ability to using container operators on serialized,=20
multi-type sets is idiomatic in the languages that have been addressing the=
=20
usage patterns longer than C++ users. We should nod to their wisdom on the=
=20
matter.



They can't even do `tpl[c<x>()]`, which to a newbie makes perfect sense.=20
The compiler will give them some funny error they don't understand.

If we're going to start speculating about what newcomers would expect, I=20
think it's just as reasonable to think that, if you give them indexing,=20
they'll expect *integer* indexing. At least with `std::get`, the interface=
=20
is so different that there is less of a surprise when `get<x>` errors out.


Now that I do agree with. We can alter the implementation a little bit to=
=20
allow both integer access and std iterator.

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

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

<div dir=3D"ltr">On Sunday, October 18, 2015 at 7:02:58 PM UTC-6, Nicol Bol=
as wrote:On Sunday, October 18, 2015 at 8:23:09 PM UTC-4, Germ=C3=A1n Diago=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">The problem I see is, that th=
e behaviours is utterly inconsistent with other standard types. </div></blo=
ckquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">So you expect the operator[] to always return the same type.</div>=
</blockquote><div>=C2=A0</div><div>=C2=A0II tend to look at this as indexin=
g an ordered sequence. Makes sense. Why should the type be the same?<br><br=
>Because pretty much every other index-able class returns the same type fro=
m its operator[].<br></div></div></blockquote><br>Tuple is a unique and rec=
ent feature that is rather different from most existing features. The close=
st pre-existing features are std::pair and structs. There&#39;s nothing str=
ange about equipping pairs with these operators, that&#39;d be rather usefu=
l actually. On the other hand iterating through a struct would be quite a h=
assle. Especially, operator-based element access for tuple values is natura=
l given the role tuples fill in a language that already had pair&lt;int,pai=
r&lt;int,..&gt;&gt; and structs.<br><br><blockquote style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=
 class=3D"gmail_quote">A minimum expectation from whom?<br>...<br></blockqu=
ote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>I think the first thin=
g a newcomer to C++=C2=A0</div><div>would expect from a tuple is to be able=
 to index them.</div></div></blockquote><br>A
 newcomer from some other language with native tuples? Possibly. But=20
from other near-C++ languages (like Java or C#, neither of which have []
 indexing), or simply neophyte programmers? Their first question will=20
be... what&#39;s a tuple?<br><br>And from the description, I doubt they&#39=
;ll expect to be able to index it.<br></blockquote><br>Tuples were brought =
in to fill blanks common to=20
many higher level languages. The ability to using container operators on
 serialized, multi-type sets is idiomatic in the languages that have=20
been addressing the usage patterns longer than C++ users. We should nod=20
to their wisdom on the matter.<br><br><br><br><blockquote>They can&#39;t ev=
en do `tpl[c&lt;x&gt;()]`, which to a newbie makes perfect=20
sense. The compiler will give them some funny error they don&#39;t=20
understand.<br><br>If we&#39;re going to start speculating about what=20
newcomers would expect, I think it&#39;s just as reasonable to think that,=
=20
if you give them indexing, they&#39;ll expect <i>integer</i> indexing. At=
=20
least with `std::get`, the interface is so different that there is less=20
of a surprise when `get&lt;x&gt;` errors out.<br></blockquote><div><br>Now =
that I do agree with. We can alter the implementation a little bit to allow=
 both integer access and std iterator.<br><br>=C2=A0<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_1385_706730675.1446842190968--
------=_Part_1384_924867365.1446842190967--

.

------=_Part_357_1222492632.1446842479922
Content-Type: multipart/alternative;
 boundary="----=_Part_358_1603343785.1446842479922"

------=_Part_358_1603343785.1446842479922
Content-Type: text/plain; charset=UTF-8



>
>
>> If C++ gets the ability to use regular old integer variables with tuple
>> access, I'd be more willing to see operator[] work on it. But unless
>> `operator[]` is going to behave like regular `operator[]` overloads (ie:
>> operating on seemingly runtime values), then I don't see the point. If
>> retrieving elements of a tuple has to be done using different syntax from
>> other types, I'd rather that the syntax be *very* different.
>>
>
> Cannot be done, but that proposal is pretty close to that ideal and is
> more uniform than having std::get<N>.
>

Has been done using templates

--

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

<div dir=3D"ltr"><div><br></div><blockquote style=3D"margin: 0px 0px 0px 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=
=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>If

 C++ gets the ability to use regular old integer variables with tuple=20
access, I&#39;d be more willing to see operator[] work on it. But unless=20
`operator[]` is going to behave like regular `operator[]` overloads (ie:
 operating=20
on seemingly runtime values), then I don&#39;t see the point. If retrieving=
=20
elements of a tuple has to be done using different syntax from other=20
types, I&#39;d rather that the syntax be <i>very</i> different.<br></div></=
div></blockquote><div><br>Cannot be done, but that proposal is pretty close=
 to that ideal and is more uniform than having std::get&lt;N&gt;.<br></div>=
</blockquote><br>Has been done using templates <br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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_358_1603343785.1446842479922--
------=_Part_357_1222492632.1446842479922--

.