------=_Part_6758_1348839570.1501754186548
Content-Type: multipart/alternative;
 boundary="----=_Part_6759_1223787038.1501754186548"

------=_Part_6759_1223787038.1501754186548
Content-Type: text/plain; charset="UTF-8"

Today when you declare more than one variable using 'auto' the auto keyword
must resolve to the same type for all initializers. Personally I think this
was the wrong decision from the get go and over time this seems to keep
creating inconsistencies that the already complex C++ language does not
need:

auto x=1, y=2.0;    // error

auto lambda = [](auto... xs) {};

lambda(1, 2.0)     // ok

Now people are saying that in the upcoming concepts world that concepts
used in terse templates (initially lambdas) shall bind to the same type for
all parameters, with reference to congruence with auto variable
declarations:

concept Regular = ...;

auto clambda = [](Regular... xs);

clambda(1, 2.0);     // Error, don't know what type each xs should have.


I think this smells very bad and therefore boldly suggest to change the
rule for auto variables to allow:

auto x=1, y = 2.0;   // x is an int, y is a double.

Also don't forget my original reason for allowing this:

for (auto i=0, iter = vec.begin(); iter != vec.end(); i++, iter++)
    *iter = i;


So the main issue is: Does this break code? Are there cases which are
currently allowed which would subtly change meaning? Maybe:

Base* bp;
Sub* sp;

auto bp2 = bp, sp2 = sp;

But this does not compile on VS2015 at least, giving an expected error
message.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9afdc1e-c007-455c-870d-0e0c41f36d80%40isocpp.org.

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

<div dir=3D"ltr">Today when you declare more than one variable using &#39;a=
uto&#39; the auto keyword must resolve to the same type for all initializer=
s. Personally I think this was the wrong decision from the get go and over =
time this seems to keep creating inconsistencies that the already complex C=
++ language does not need:<div><br></div><div>auto x=3D1, y=3D2.0; =C2=A0 =
=C2=A0// error</div><div><br></div><div>auto lambda =3D [](auto... xs) {};<=
/div><div><br></div><div>lambda(1, 2.0) =C2=A0 =C2=A0 // ok</div><div><br><=
/div><div>Now people are saying that in the upcoming concepts world that co=
ncepts used in terse templates (initially lambdas) shall bind to the same t=
ype for all parameters, with reference to congruence with auto variable dec=
larations:</div><div><br></div><div>concept Regular =3D ...;</div><div><br>=
</div><div>auto clambda =3D [](Regular... xs);</div><div><br></div><div>cla=
mbda(1, 2.0); =C2=A0 =C2=A0 // Error, don&#39;t know what type each xs shou=
ld have.</div><div><br></div><div><br></div><div>I think this smells very b=
ad and therefore boldly suggest to change the rule for auto variables to al=
low:</div><div><br></div><div>auto x=3D1, y =3D 2.0; =C2=A0 // x is an int,=
 y is a double.</div><div><br></div><div>Also don&#39;t forget my original =
reason for allowing this:</div><div><br></div><div>for (auto i=3D0, iter =
=3D vec.begin(); iter !=3D vec.end(); i++, iter++)</div><div>=C2=A0 =C2=A0 =
*iter =3D i;</div><div><br></div><div><br></div><div>So the main issue is: =
Does this break code? Are there cases which are currently allowed which wou=
ld subtly change meaning? Maybe:</div><div><br></div><div>Base* bp;</div><d=
iv>Sub* sp;</div><div><br></div><div>auto bp2 =3D bp, sp2 =3D sp;</div><div=
><br></div><div>But this does not compile on VS2015 at least, giving an exp=
ected error message.</div></div>

<p></p>

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

------=_Part_6759_1223787038.1501754186548--

------=_Part_6758_1348839570.1501754186548--

.

--94eb2c140130ee3dea0555d81d5b
Content-Type: text/plain; charset="UTF-8"

The "terse syntax" will be bikeshedded a lot - it is the part of the TS
that wasn't merged because of various concerns, and there will be lots of
EWG discussions at upcoming meetings.

Your "fix" doesn't actually fix anything, it just makes it somewhat
compatible with a mostly rejected idea of how the terse syntax should work.
I don't think this can fly at all, and the `for` use case is a very weak
one IMO (can't remember the last time I actually had a need for `for` loop
variables of multiple types).

On Thu, Aug 3, 2017 at 11:56 AM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> Today when you declare more than one variable using 'auto' the auto
> keyword must resolve to the same type for all initializers. Personally I
> think this was the wrong decision from the get go and over time this seems
> to keep creating inconsistencies that the already complex C++ language does
> not need:
>
> auto x=1, y=2.0;    // error
>
> auto lambda = [](auto... xs) {};
>
> lambda(1, 2.0)     // ok
>
> Now people are saying that in the upcoming concepts world that concepts
> used in terse templates (initially lambdas) shall bind to the same type for
> all parameters, with reference to congruence with auto variable
> declarations:
>
> concept Regular = ...;
>
> auto clambda = [](Regular... xs);
>
> clambda(1, 2.0);     // Error, don't know what type each xs should have.
>
>
> I think this smells very bad and therefore boldly suggest to change the
> rule for auto variables to allow:
>
> auto x=1, y = 2.0;   // x is an int, y is a double.
>
> Also don't forget my original reason for allowing this:
>
> for (auto i=0, iter = vec.begin(); iter != vec.end(); i++, iter++)
>     *iter = i;
>
>
> So the main issue is: Does this break code? Are there cases which are
> currently allowed which would subtly change meaning? Maybe:
>
> Base* bp;
> Sub* sp;
>
> auto bp2 = bp, sp2 = sp;
>
> But this does not compile on VS2015 at least, giving an expected error
> message.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9afdc1e-c007-455c-870d-0e0c41f36d80%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9afdc1e-c007-455c-870d-0e0c41f36d80%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--94eb2c140130ee3dea0555d81d5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The &quot;terse syntax&quot; will be bikeshedded a lot - i=
t is the part of the TS that wasn&#39;t merged because of various concerns,=
 and there will be lots of EWG discussions at upcoming meetings.<div><br></=
div><div>Your &quot;fix&quot; doesn&#39;t actually fix anything, it just ma=
kes it somewhat compatible with a mostly rejected idea of how the terse syn=
tax should work. I don&#39;t think this can fly at all, and the `for` use c=
ase is a very weak one IMO (can&#39;t remember the last time I actually had=
 a need for `for` loop variables of multiple types).</div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Thu, Aug 3, 2017 at 11:56 AM Bengt =
Gustafsson &lt;<a href=3D"mailto:bengt.gustafsson@beamways.com">bengt.gusta=
fsson@beamways.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">Today when you declare more than one variable using &#39;au=
to&#39; the auto keyword must resolve to the same type for all initializers=
.. Personally I think this was the wrong decision from the get go and over t=
ime this seems to keep creating inconsistencies that the already complex C+=
+ language does not need:<div><br></div><div>auto x=3D1, y=3D2.0; =C2=A0 =
=C2=A0// error</div><div><br></div><div>auto lambda =3D [](auto... xs) {};<=
/div><div><br></div><div>lambda(1, 2.0) =C2=A0 =C2=A0 // ok</div><div><br><=
/div><div>Now people are saying that in the upcoming concepts world that co=
ncepts used in terse templates (initially lambdas) shall bind to the same t=
ype for all parameters, with reference to congruence with auto variable dec=
larations:</div><div><br></div><div>concept Regular =3D ...;</div><div><br>=
</div><div>auto clambda =3D [](Regular... xs);</div><div><br></div><div>cla=
mbda(1, 2.0); =C2=A0 =C2=A0 // Error, don&#39;t know what type each xs shou=
ld have.</div><div><br></div><div><br></div><div>I think this smells very b=
ad and therefore boldly suggest to change the rule for auto variables to al=
low:</div><div><br></div><div>auto x=3D1, y =3D 2.0; =C2=A0 // x is an int,=
 y is a double.</div><div><br></div><div>Also don&#39;t forget my original =
reason for allowing this:</div><div><br></div><div>for (auto i=3D0, iter =
=3D vec.begin(); iter !=3D vec.end(); i++, iter++)</div><div>=C2=A0 =C2=A0 =
*iter =3D i;</div><div><br></div><div><br></div><div>So the main issue is: =
Does this break code? Are there cases which are currently allowed which wou=
ld subtly change meaning? Maybe:</div><div><br></div><div>Base* bp;</div><d=
iv>Sub* sp;</div><div><br></div><div>auto bp2 =3D bp, sp2 =3D sp;</div><div=
><br></div><div>But this does not compile on VS2015 at least, giving an exp=
ected error message.</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b9afdc1e-c007-455c-870d-0e0c41f36d80%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9afdc1e-c007-=
455c-870d-0e0c41f36d80%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--94eb2c140130ee3dea0555d81d5b--

.

------=_Part_2531_727728269.1501776962357
Content-Type: multipart/alternative;
 boundary="----=_Part_2532_1332575478.1501776962358"

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

Le jeudi 3 ao=C3=BBt 2017 11:56:26 UTC+2, Bengt Gustafsson a =C3=A9crit :
>
> auto x=3D1, y=3D2.0;    // error
>
> for (auto i=3D0, iter =3D vec.begin(); iter !=3D vec.end(); i++, iter++)
>     *iter =3D i;
>
> Base* bp;
> Sub* sp;
> auto bp2 =3D bp, sp2 =3D sp;
>
> You can write all of this using structured binding.=20
auto [x, y] =3D std::tuple{1, 2.0};

for (auto [i, iter] =3D std::tuple{0, vec.begin()}; iter !=3D vec.end(), (i=
++,=20
iter++))
    *iter =3D i;

Base *bp;
Sub *sp;
auto [bp2, sp2] =3D std::tuple{bp, sp};

The best you can ask is for structured binding on brace-init list.
auto[x,y] =3D {1, 3.0};

But the truth is that nobody wants to have complex for loops and declaring=
=20
bp2 and sp2 is nonsensical.
Declaring a bunch of unrelated stuff in one line is not a good thing and I=
=20
don't see anyone using it in production code.
It's as useful as writing functions without line breaks, you've reduced the=
=20
line count and with it readability.

template <class T, size_t N =3D sizeof(T::elem)> static constexpr auto func=
(T
&&l, T&&r) { return v.func(r); }

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

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

<div dir=3D"ltr">Le jeudi 3 ao=C3=BBt 2017 11:56:26 UTC+2, Bengt Gustafsson=
 a =C3=A9crit=C2=A0:<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 class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">=3D</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">2.0</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> =C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// error</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">for</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> iter </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> vec</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">begin</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> iter </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> vec</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">++,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i=
ter</span><span style=3D"color: #660;" class=3D"styled-by-prettify">++)</sp=
an><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-prettify">*</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">iter </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Base</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> bp</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: #606;" class=3D"styled-by-prettify">Sub</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> sp</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> bp2 </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> bp</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s=
p2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> sp</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></code>=
</div><div><br></div></div></blockquote><div>You can write all of this usin=
g structured binding.=C2=A0</div><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: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">tuple</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">2.0</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: #008;" cl=
ass=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> iter</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</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: #000;" class=3D"styled-by-prettify">tuple</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> vec</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">begin</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()};</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> iter </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v=
ec</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">end</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">++,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> iter</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: #660;" class=3D"styled-by-pre=
ttify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">it=
er </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Base</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">bp</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: #606;" class=3D"styled-by-prettify">Sub</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">sp</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
bp2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> sp2</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">]</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">tuple</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">bp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> sp</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code>=
</div><div><br></div><div>The best you can ask is for structured binding on=
 brace-init list.</div><div><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">y</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">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">3.0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></div>=
<div><br></div>But the truth is that nobody wants to have complex for loops=
 and declaring bp2 and sp2 is nonsensical.</div><div>Declaring a bunch of u=
nrelated stuff in one line is not a good thing and I don&#39;t see anyone u=
sing it in production code.</div><div>It&#39;s as useful as writing functio=
ns without line breaks, you&#39;ve reduced the line count and with it reada=
bility.<br></div><div><br></div><div><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t N </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">elem</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">sta=
tic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&amp;&amp;</span><font color=3D"#000000"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">l</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">r</span></font><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">func</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">r</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
></div></code></div></div></div>

<p></p>

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

------=_Part_2532_1332575478.1501776962358--

------=_Part_2531_727728269.1501776962357--

.

On 2017-08-03 11:56, Bengt Gustafsson wrote:
> Today when you declare more than one variable using 'auto' the auto
> keyword must resolve to the same type for all initializers. Personally I
> think this was the wrong decision from the get go and over time this
> seems to keep creating inconsistencies that the already complex C++
> language does not need:
>
> auto x=1, y=2.0;    // error
>
> auto lambda = [](auto... xs) {};
>
> lambda(1, 2.0)     // ok
>
> Now people are saying that in the upcoming concepts world that concepts
> used in terse templates (initially lambdas) shall bind to the same type
> for all parameters, with reference to congruence with auto variable
> declarations:
>
> concept Regular = ...;
>
> auto clambda = [](Regular... xs);
>
> clambda(1, 2.0);     // Error, don't know what type each xs should have.
>
>
> I think this smells very bad and therefore boldly suggest to change the
> rule for auto variables to allow:
>
> auto x=1, y = 2.0;   // x is an int, y is a double.
>
> Also don't forget my original reason for allowing this:
>
> for (auto i=0, iter = vec.begin(); iter != vec.end(); i++, iter++)
>      *iter = i;
>
>
> So the main issue is: Does this break code? Are there cases which are
> currently allowed which would subtly change meaning?


Perhaps not, but it invites new bugs where you *intended* the types to
be the same but a small typo caused one value to be different.

auto x = 1.0, y = 2.0, z = 3.0, w = 40;


     Bo Persson


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/om0v9h%2499u%241%40blaine.gmane.org.

.

------=_Part_1296_747960205.1501885361502
Content-Type: multipart/alternative;
 boundary="----=_Part_1297_1591479918.1501885361502"

------=_Part_1297_1591479918.1501885361502
Content-Type: text/plain; charset="UTF-8"



Den fredag 4 augusti 2017 kl. 07:05:13 UTC+2 skrev Bo Persson:
>
> On 2017-08-03 11:56, Bengt Gustafsson wrote:
> > Today when you declare more than one variable using 'auto' the auto
> > keyword must resolve to the same type for all initializers. Personally I
> > think this was the wrong decision from the get go and over time this
> > seems to keep creating inconsistencies that the already complex C++
> > language does not need:
> >
> > auto x=1, y=2.0;    // error
> >
> > auto lambda = [](auto... xs) {};
> >
> > lambda(1, 2.0)     // ok
> >
> > Now people are saying that in the upcoming concepts world that concepts
> > used in terse templates (initially lambdas) shall bind to the same type
> > for all parameters, with reference to congruence with auto variable
> > declarations:
> >
> > concept Regular = ...;
> >
> > auto clambda = [](Regular... xs);
> >
> > clambda(1, 2.0);     // Error, don't know what type each xs should have.
> >
> >
> > I think this smells very bad and therefore boldly suggest to change the
> > rule for auto variables to allow:
> >
> > auto x=1, y = 2.0;   // x is an int, y is a double.
> >
> > Also don't forget my original reason for allowing this:
> >
> > for (auto i=0, iter = vec.begin(); iter != vec.end(); i++, iter++)
> >      *iter = i;
> >
> >
> > So the main issue is: Does this break code? Are there cases which are
> > currently allowed which would subtly change meaning?
>
>
> Perhaps not, but it invites new bugs where you *intended* the types to
> be the same but a small typo caused one value to be different.
>
> auto x = 1.0, y = 2.0, z = 3.0, w = 40;
>
>
>      Bo Persson
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe20e33c-70ac-41c1-a7ce-5ec37e5c487b%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Den fredag 4 augusti 2017 kl. 07:05:13 UTC+2 skrev=
 Bo Persson:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08-03 11:5=
6, Bengt Gustafsson wrote:
<br>&gt; Today when you declare more than one variable using &#39;auto&#39;=
 the auto=20
<br>&gt; keyword must resolve to the same type for all initializers. Person=
ally I=20
<br>&gt; think this was the wrong decision from the get go and over time th=
is=20
<br>&gt; seems to keep creating inconsistencies that the already complex C+=
+=20
<br>&gt; language does not need:
<br>&gt;=20
<br>&gt; auto x=3D1, y=3D2.0; =C2=A0 =C2=A0// error
<br>&gt;=20
<br>&gt; auto lambda =3D [](auto... xs) {};
<br>&gt;=20
<br>&gt; lambda(1, 2.0) =C2=A0 =C2=A0 // ok
<br>&gt;=20
<br>&gt; Now people are saying that in the upcoming concepts world that con=
cepts=20
<br>&gt; used in terse templates (initially lambdas) shall bind to the same=
 type=20
<br>&gt; for all parameters, with reference to congruence with auto variabl=
e=20
<br>&gt; declarations:
<br>&gt;=20
<br>&gt; concept Regular =3D ...;
<br>&gt;=20
<br>&gt; auto clambda =3D [](Regular... xs);
<br>&gt;=20
<br>&gt; clambda(1, 2.0); =C2=A0 =C2=A0 // Error, don&#39;t know what type =
each xs should have.
<br>&gt;=20
<br>&gt;=20
<br>&gt; I think this smells very bad and therefore boldly suggest to chang=
e the=20
<br>&gt; rule for auto variables to allow:
<br>&gt;=20
<br>&gt; auto x=3D1, y =3D 2.0; =C2=A0 // x is an int, y is a double.
<br>&gt;=20
<br>&gt; Also don&#39;t forget my original reason for allowing this:
<br>&gt;=20
<br>&gt; for (auto i=3D0, iter =3D vec.begin(); iter !=3D vec.end(); i++, i=
ter++)
<br>&gt; =C2=A0 =C2=A0 =C2=A0*iter =3D i;
<br>&gt;=20
<br>&gt;=20
<br>&gt; So the main issue is: Does this break code? Are there cases which =
are=20
<br>&gt; currently allowed which would subtly change meaning?=20
<br>
<br>
<br>Perhaps not, but it invites new bugs where you *intended* the types to=
=20
<br>be the same but a small typo caused one value to be different.
<br>
<br>auto x =3D 1.0, y =3D 2.0, z =3D 3.0, w =3D 40;
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson
<br>
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_1297_1591479918.1501885361502--

------=_Part_1296_747960205.1501885361502--

.

------=_Part_1276_1886414876.1501886061517
Content-Type: multipart/alternative;
 boundary="----=_Part_1277_147068002.1501886061517"

------=_Part_1277_147068002.1501886061517
Content-Type: text/plain; charset="UTF-8"

There are so many other ways to create bugs. For instance the new
possibility:

tuple(1.0, 2.0, 3.0, 40)

Why can we expect people to get this right, but not auto variables.

But this is not my point, but rather to make the language more consistent.
I think that consistency means fewer rules to learn, which means that
people tend to know more about the language and when they transfer
knowledge from one place to another it is more likely to still be valid. In
this case the main pain point is variadic lambdas:

[](auto... xs) {}

where each 'auto' means a different type. We can't change this to force it
to mean "the same type" which is why I asked whether there was blocking
reasons for not changing the meaning of auto variable declarations.

And then, after having such lambdas included in the language it seems that
we will get this:

[](Regular... xs) {}

and now all xs will be bound to the same type! Motivation: This is how auto
variables work: duh!

So my point is that as we can't reasonably have auto... in lambdas mean
"the same type" we should investigate if we can have it the other way
around in all applicable places.


Den fredag 4 augusti 2017 kl. 07:05:13 UTC+2 skrev Bo Persson:
>
> On 2017-08-03 11:56, Bengt Gustafsson wrote:
> > Today when you declare more than one variable using 'auto' the auto
> > keyword must resolve to the same type for all initializers. Personally I
> > think this was the wrong decision from the get go and over time this
> > seems to keep creating inconsistencies that the already complex C++
> > language does not need:
> >
> > auto x=1, y=2.0;    // error
> >
> > auto lambda = [](auto... xs) {};
> >
> > lambda(1, 2.0)     // ok
> >
> > Now people are saying that in the upcoming concepts world that concepts
> > used in terse templates (initially lambdas) shall bind to the same type
> > for all parameters, with reference to congruence with auto variable
> > declarations:
> >
> > concept Regular = ...;
> >
> > auto clambda = [](Regular... xs);
> >
> > clambda(1, 2.0);     // Error, don't know what type each xs should have.
> >
> >
> > I think this smells very bad and therefore boldly suggest to change the
> > rule for auto variables to allow:
> >
> > auto x=1, y = 2.0;   // x is an int, y is a double.
> >
> > Also don't forget my original reason for allowing this:
> >
> > for (auto i=0, iter = vec.begin(); iter != vec.end(); i++, iter++)
> >      *iter = i;
> >
> >
> > So the main issue is: Does this break code? Are there cases which are
> > currently allowed which would subtly change meaning?
>
>
> Perhaps not, but it invites new bugs where you *intended* the types to
> be the same but a small typo caused one value to be different.
>
> auto x = 1.0, y = 2.0, z = 3.0, w = 40;
>
>
>      Bo Persson
>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/378e8adc-b69d-425b-a532-e969435fd990%40isocpp.org.

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

<div dir=3D"ltr">There are so many other ways to create bugs. For instance =
the new possibility:<div><br></div><div>tuple(1.0, 2.0, 3.0, 40)</div><div>=
<br></div><div>Why can we expect people to get this right, but not auto var=
iables.</div><div><br></div><div>But this is not my point, but rather to ma=
ke the language more consistent. I think that consistency means fewer rules=
 to learn, which means that people tend to know more about the language and=
 when they transfer knowledge from one place to another it is more likely t=
o still be valid. In this case the main pain point is variadic lambdas:</di=
v><div><br></div><div>[](auto... xs) {}</div><div><br></div><div>where each=
 &#39;auto&#39; means a different type. We can&#39;t change this to force i=
t to mean &quot;the same type&quot; which is why I asked whether there was =
blocking reasons for not changing the meaning of auto variable declarations=
..</div><div><br></div><div>And then, after having such lambdas included in =
the language it seems that we will get this:</div><div><br></div><div>[](Re=
gular... xs) {}</div><div><br></div><div>and now all xs will be bound to th=
e same type! Motivation: This is how auto variables work: duh!</div><div><b=
r></div><div>So my point is that as we can&#39;t reasonably have auto... in=
 lambdas mean &quot;the same type&quot; we should investigate if we can hav=
e it the other way around in all applicable places.</div><div><br></div><di=
v><br>Den fredag 4 augusti 2017 kl. 07:05:13 UTC+2 skrev Bo Persson:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On 2017-08-03 11:56, Bengt Gustafsson=
 wrote:
<br>&gt; Today when you declare more than one variable using &#39;auto&#39;=
 the auto=20
<br>&gt; keyword must resolve to the same type for all initializers. Person=
ally I=20
<br>&gt; think this was the wrong decision from the get go and over time th=
is=20
<br>&gt; seems to keep creating inconsistencies that the already complex C+=
+=20
<br>&gt; language does not need:
<br>&gt;=20
<br>&gt; auto x=3D1, y=3D2.0; =C2=A0 =C2=A0// error
<br>&gt;=20
<br>&gt; auto lambda =3D [](auto... xs) {};
<br>&gt;=20
<br>&gt; lambda(1, 2.0) =C2=A0 =C2=A0 // ok
<br>&gt;=20
<br>&gt; Now people are saying that in the upcoming concepts world that con=
cepts=20
<br>&gt; used in terse templates (initially lambdas) shall bind to the same=
 type=20
<br>&gt; for all parameters, with reference to congruence with auto variabl=
e=20
<br>&gt; declarations:
<br>&gt;=20
<br>&gt; concept Regular =3D ...;
<br>&gt;=20
<br>&gt; auto clambda =3D [](Regular... xs);
<br>&gt;=20
<br>&gt; clambda(1, 2.0); =C2=A0 =C2=A0 // Error, don&#39;t know what type =
each xs should have.
<br>&gt;=20
<br>&gt;=20
<br>&gt; I think this smells very bad and therefore boldly suggest to chang=
e the=20
<br>&gt; rule for auto variables to allow:
<br>&gt;=20
<br>&gt; auto x=3D1, y =3D 2.0; =C2=A0 // x is an int, y is a double.
<br>&gt;=20
<br>&gt; Also don&#39;t forget my original reason for allowing this:
<br>&gt;=20
<br>&gt; for (auto i=3D0, iter =3D vec.begin(); iter !=3D vec.end(); i++, i=
ter++)
<br>&gt; =C2=A0 =C2=A0 =C2=A0*iter =3D i;
<br>&gt;=20
<br>&gt;=20
<br>&gt; So the main issue is: Does this break code? Are there cases which =
are=20
<br>&gt; currently allowed which would subtly change meaning?=20
<br>
<br>
<br>Perhaps not, but it invites new bugs where you *intended* the types to=
=20
<br>be the same but a small typo caused one value to be different.
<br>
<br>auto x =3D 1.0, y =3D 2.0, z =3D 3.0, w =3D 40;
<br>
<br>
<br>=C2=A0 =C2=A0 =C2=A0Bo Persson
<br>
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_1277_147068002.1501886061517--

------=_Part_1276_1886414876.1501886061517--

.

------=_Part_1271_1978556844.1501887465648
Content-Type: multipart/alternative;
 boundary="----=_Part_1272_599423720.1501887465649"

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

On Friday, August 4, 2017 at 3:34:21 PM UTC-7, Bengt Gustafsson wrote:
>
>
> But this is not my point, but rather to make the language more consistent=
..=20
> I think that consistency means fewer rules to learn, which means that=20
> people tend to know more about the language and when they transfer=20
> knowledge from one place to another it is more likely to still be valid. =
In=20
> this case the main pain point is variadic lambdas:
>
> [](auto... xs) {}
>
> where each 'auto' means a different type.
>

Right, this is just a pack-expansion. I believe the current=20
syntax/semantics is perfectly teachable. Namely:
- Any time you see "..." (as long as it doesn't mean C-style variadic=20
arguments), you take the thing before it and expand it out like a pack.
- That's pretty much the only rule.

So for example

    template<class... Ts>
    void foo(Ts... ts) { }

means

    template<class Ta, class Tb, class Tc, etc...>
    void foo(Ta ta, Tb tb, Tc tc, etc...) { }

and likewise,

    [](auto... xs) { }

means

    [](auto xa, auto xb, auto xc, etc...) { }

To have "..." work *differently* in lambdas from how it does in the rest of=
=20
the language would make C++ harder to teach, IMNSHO. It would also make the=
=20
language significantly harder for the *compiler*, because the compiler=20
would suddenly have to keep track of which expanded "auto" keywords came=20
from the source code and which ones came from pack-expansions (in order to=
=20
make the pack-expanded ones behave "as a group" while the hand-written ones=
=20
behaved independently).

And then, after having such lambdas included in the language it seems that=
=20
> we will get this:
>
> [](Regular... xs) {}
>
> and now all xs will be bound to the same type! Motivation: This is how=20
> auto variables work: duh!
>

Well no, the Concepts Lite proposal (the controversial "terse syntax")=20
includes this case, and it has "Regular..." expanding out to "Regular,=20
Regular, Regular, etc..." just the same way all other pack-expansions work.=
=20
The "Regular"s don't have to bind to the same type; they merely apply the=
=20
*same* (Regular) *constraint* to whatever types wind up getting bound.
See N3580=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3580.pdf> section=
=20
4.5.1, "Variadic Constraints".

This is similar to how when we write

    void foo(int x, int y) { }

we expect that *values* x and y will have the same type (int), but be=20
possibly different *values* of int. Likewise when we write

    template<class A, class B>
    void foo(A x, B y) requires (Regular<A>, Regular<B>) { }

we expect that *types* A and B will model the same constraint (Regular),=20
but be possibly different *types* modeling Regular.
And throwing in variadic templates and "terse syntax" sugar doesn't change=
=20
anything about our mental model of the semantics here:

    template<class... Ts>
    void foo(Ts... xs) requires (Regular<Ts>...) { }   // argument types=20
are still heterogeneous

    template<Regular... Ts>
    void foo(Ts... xs) { }   // argument types are still heterogeneous

    void foo(Regular... xs) { }   // argument types are still heterogeneous

HTH,
=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Friday, August 4, 2017 at 3:34:21 PM UTC-7, Bengt Gusta=
fsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br></div><div>But this is not my point, but rather to make the languag=
e more consistent. I think that consistency means fewer rules to learn, whi=
ch means that people tend to know more about the language and when they tra=
nsfer knowledge from one place to another it is more likely to still be val=
id. In this case the main pain point is variadic lambdas:</div><div><br></d=
iv><div>[](auto... xs) {}</div><div><br></div><div>where each &#39;auto&#39=
; means a different type.</div></div></blockquote><div><br></div><div>Right=
, this is just a pack-expansion. I believe the current syntax/semantics is =
perfectly teachable. Namely:</div><div>- Any time you see &quot;...&quot; (=
as long as it doesn&#39;t mean C-style variadic arguments), you take the th=
ing before it and expand it out like a pack.</div><div>- That&#39;s pretty =
much the only rule.</div><div><br></div><div>So for example</div><div><br><=
/div><div>=C2=A0 =C2=A0 template&lt;class... Ts&gt;</div><div>=C2=A0 =C2=A0=
 void foo(Ts... ts) { }</div><div><br></div><div>means</div><div><br></div>=
<div>=C2=A0 =C2=A0 template&lt;class Ta, class Tb, class Tc, etc...&gt;</di=
v><div>=C2=A0 =C2=A0 void foo(Ta ta, Tb tb, Tc tc, etc...) { }</div><div><b=
r></div><div>and likewise,</div><div><br></div><div>=C2=A0 =C2=A0 [](auto..=
.. xs) { }</div><div><br></div><div>means</div><div><br></div><div>=C2=A0 =
=C2=A0 [](auto xa, auto xb, auto xc, etc...) { }</div><div><br></div><div>T=
o have &quot;...&quot; work <i>differently</i> in lambdas from how it does =
in the rest of the language would make C++ harder to teach, IMNSHO. It woul=
d also make the language significantly harder for the <i>compiler</i>, beca=
use the compiler would suddenly have to keep track of which expanded &quot;=
auto&quot; keywords came from the source code and which ones came from pack=
-expansions (in order to make the pack-expanded ones behave &quot;as a grou=
p&quot; while the hand-written ones behaved independently).</div><div><br><=
/div><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"><div>And=
 then, after having such lambdas included in the language it seems that we =
will get this:</div><div><br></div><div>[](Regular... xs) {}</div><div><br>=
</div><div>and now all xs will be bound to the same type! Motivation: This =
is how auto variables work: duh!</div></div></blockquote><div><br></div><di=
v>Well no, the Concepts Lite proposal (the controversial &quot;terse syntax=
&quot;) includes this case, and it has &quot;Regular...&quot; expanding out=
 to &quot;Regular, Regular, Regular, etc...&quot; just the same way all oth=
er pack-expansions work. The &quot;Regular&quot;s don&#39;t have to bind to=
 the same type; they merely apply the <i>same</i> (Regular) <i>constraint</=
i> to whatever types wind up getting bound.</div><div>See <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3580.pdf">N3580</a> sect=
ion 4.5.1, &quot;Variadic Constraints&quot;.</div><div><br></div><div>This =
is similar to how when we write</div><div><br></div><div>=C2=A0 =C2=A0 void=
 foo(int x, int y) { }</div><div><br></div><div>we expect that <i>values</i=
> x and y will have the same type (int), but be possibly different <i>value=
s</i> of int. Likewise when we write</div><div><br></div><div>=C2=A0 =C2=A0=
 template&lt;class A, class B&gt;</div><div>=C2=A0 =C2=A0 void foo(A x, B y=
) requires (Regular&lt;A&gt;, Regular&lt;B&gt;) { }</div><div><br></div><di=
v>we expect that <i>types</i> A and B will model the same constraint (Regul=
ar), but be possibly different <i>types</i> modeling Regular.</div><div>And=
 throwing in variadic templates and &quot;terse syntax&quot; sugar doesn&#3=
9;t change anything about our mental model of the semantics here:</div><div=
><br></div><div><div>=C2=A0 =C2=A0 template&lt;class... Ts&gt;</div><div>=
=C2=A0 =C2=A0 void foo(Ts... xs) requires (Regular&lt;Ts&gt;...) { } =C2=A0=
 // argument types are still heterogeneous</div><div><br></div></div><div><=
div>=C2=A0 =C2=A0 template&lt;Regular... Ts&gt;</div><div>=C2=A0 =C2=A0 voi=
d foo(Ts... xs) { } =C2=A0 // argument types are still heterogeneous</div><=
/div><div><br></div><div><div>=C2=A0 =C2=A0 void foo(Regular... xs) { } =C2=
=A0 // argument types are still heterogeneous<br></div></div><div><br></div=
><div>HTH,</div><div>=E2=80=93Arthur<br></div></div>

<p></p>

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

------=_Part_1272_599423720.1501887465649--

------=_Part_1271_1978556844.1501887465648--

.

--001a11473c6496c1870555f64afb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

@Arthur,: for what it's worth, I'd also like for Regular... to behave like
auto... but the jury's still out on this one, so let's keep an open mind :/

2017-08-04 18:57 GMT-04:00 Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

> On Friday, August 4, 2017 at 3:34:21 PM UTC-7, Bengt Gustafsson wrote:
>>
>>
>> But this is not my point, but rather to make the language more
>> consistent. I think that consistency means fewer rules to learn, which
>> means that people tend to know more about the language and when they
>> transfer knowledge from one place to another it is more likely to still =
be
>> valid. In this case the main pain point is variadic lambdas:
>>
>> [](auto... xs) {}
>>
>> where each 'auto' means a different type.
>>
>
> Right, this is just a pack-expansion. I believe the current
> syntax/semantics is perfectly teachable. Namely:
> - Any time you see "..." (as long as it doesn't mean C-style variadic
> arguments), you take the thing before it and expand it out like a pack.
> - That's pretty much the only rule.
>
> So for example
>
>     template<class... Ts>
>     void foo(Ts... ts) { }
>
> means
>
>     template<class Ta, class Tb, class Tc, etc...>
>     void foo(Ta ta, Tb tb, Tc tc, etc...) { }
>
> and likewise,
>
>     [](auto... xs) { }
>
> means
>
>     [](auto xa, auto xb, auto xc, etc...) { }
>
> To have "..." work *differently* in lambdas from how it does in the rest
> of the language would make C++ harder to teach, IMNSHO. It would also mak=
e
> the language significantly harder for the *compiler*, because the
> compiler would suddenly have to keep track of which expanded "auto"
> keywords came from the source code and which ones came from pack-expansio=
ns
> (in order to make the pack-expanded ones behave "as a group" while the
> hand-written ones behaved independently).
>
> And then, after having such lambdas included in the language it seems tha=
t
>> we will get this:
>>
>> [](Regular... xs) {}
>>
>> and now all xs will be bound to the same type! Motivation: This is how
>> auto variables work: duh!
>>
>
> Well no, the Concepts Lite proposal (the controversial "terse syntax")
> includes this case, and it has "Regular..." expanding out to "Regular,
> Regular, Regular, etc..." just the same way all other pack-expansions wor=
k.
> The "Regular"s don't have to bind to the same type; they merely apply the
> *same* (Regular) *constraint* to whatever types wind up getting bound.
> See N3580
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3580.pdf>
> section 4.5.1, "Variadic Constraints".
>
> This is similar to how when we write
>
>     void foo(int x, int y) { }
>
> we expect that *values* x and y will have the same type (int), but be
> possibly different *values* of int. Likewise when we write
>
>     template<class A, class B>
>     void foo(A x, B y) requires (Regular<A>, Regular<B>) { }
>
> we expect that *types* A and B will model the same constraint (Regular),
> but be possibly different *types* modeling Regular.
> And throwing in variadic templates and "terse syntax" sugar doesn't chang=
e
> anything about our mental model of the semantics here:
>
>     template<class... Ts>
>     void foo(Ts... xs) requires (Regular<Ts>...) { }   // argument types
> are still heterogeneous
>
>     template<Regular... Ts>
>     void foo(Ts... xs) { }   // argument types are still heterogeneous
>
>     void foo(Regular... xs) { }   // argument types are still heterogeneo=
us
>
> HTH,
> =E2=80=93Arthur
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/2af4b560-8823-4ae6-
> b9bf-9a00fb096c84%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2af4b560-88=
23-4ae6-b9bf-9a00fb096c84%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

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

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

<div dir=3D"ltr">@Arthur,: for what it&#39;s worth, I&#39;d also like for R=
egular... to behave like auto... but the jury&#39;s still out on this one, =
so let&#39;s keep an open mind :/<br></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">2017-08-04 18:57 GMT-04:00 Arthur O&#39;Dwyer <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_=
blank">arthur.j.odwyer@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"><span class=3D"">On Friday, August 4, 2017 at 3:34=
:21 PM UTC-7, Bengt Gustafsson wrote:<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><div>But this is not my point, but rather=
 to make the language more consistent. I think that consistency means fewer=
 rules to learn, which means that people tend to know more about the langua=
ge and when they transfer knowledge from one place to another it is more li=
kely to still be valid. In this case the main pain point is variadic lambda=
s:</div><div><br></div><div>[](auto... xs) {}</div><div><br></div><div>wher=
e each &#39;auto&#39; means a different type.</div></div></blockquote><div>=
<br></div></span><div>Right, this is just a pack-expansion. I believe the c=
urrent syntax/semantics is perfectly teachable. Namely:</div><div>- Any tim=
e you see &quot;...&quot; (as long as it doesn&#39;t mean C-style variadic =
arguments), you take the thing before it and expand it out like a pack.</di=
v><div>- That&#39;s pretty much the only rule.</div><div><br></div><div>So =
for example</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class... Ts&=
gt;</div><div>=C2=A0 =C2=A0 void foo(Ts... ts) { }</div><div><br></div><div=
>means</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;class Ta, class T=
b, class Tc, etc...&gt;</div><div>=C2=A0 =C2=A0 void foo(Ta ta, Tb tb, Tc t=
c, etc...) { }</div><div><br></div><div>and likewise,</div><div><br></div><=
div>=C2=A0 =C2=A0 [](auto... xs) { }</div><div><br></div><div>means</div><d=
iv><br></div><div>=C2=A0 =C2=A0 [](auto xa, auto xb, auto xc, etc...) { }</=
div><div><br></div><div>To have &quot;...&quot; work <i>differently</i> in =
lambdas from how it does in the rest of the language would make C++ harder =
to teach, IMNSHO. It would also make the language significantly harder for =
the <i>compiler</i>, because the compiler would suddenly have to keep track=
 of which expanded &quot;auto&quot; keywords came from the source code and =
which ones came from pack-expansions (in order to make the pack-expanded on=
es behave &quot;as a group&quot; while the hand-written ones behaved indepe=
ndently).</div><span class=3D""><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>And then, after having such lambdas inclu=
ded in the language it seems that we will get this:</div><div><br></div><di=
v>[](Regular... xs) {}</div><div><br></div><div>and now all xs will be boun=
d to the same type! Motivation: This is how auto variables work: duh!</div>=
</div></blockquote><div><br></div></span><div>Well no, the Concepts Lite pr=
oposal (the controversial &quot;terse syntax&quot;) includes this case, and=
 it has &quot;Regular...&quot; expanding out to &quot;Regular, Regular, Reg=
ular, etc...&quot; just the same way all other pack-expansions work. The &q=
uot;Regular&quot;s don&#39;t have to bind to the same type; they merely app=
ly the <i>same</i> (Regular) <i>constraint</i> to whatever types wind up ge=
tting bound.</div><div>See <a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2013/n3580.pdf" target=3D"_blank">N3580</a> section 4.5.1, &q=
uot;Variadic Constraints&quot;.</div><div><br></div><div>This is similar to=
 how when we write</div><div><br></div><div>=C2=A0 =C2=A0 void foo(int x, i=
nt y) { }</div><div><br></div><div>we expect that <i>values</i> x and y wil=
l have the same type (int), but be possibly different <i>values</i> of int.=
 Likewise when we write</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;=
class A, class B&gt;</div><div>=C2=A0 =C2=A0 void foo(A x, B y) requires (R=
egular&lt;A&gt;, Regular&lt;B&gt;) { }</div><div><br></div><div>we expect t=
hat <i>types</i> A and B will model the same constraint (Regular), but be p=
ossibly different <i>types</i> modeling Regular.</div><div>And throwing in =
variadic templates and &quot;terse syntax&quot; sugar doesn&#39;t change an=
ything about our mental model of the semantics here:</div><div><br></div><d=
iv><div>=C2=A0 =C2=A0 template&lt;class... Ts&gt;</div><div>=C2=A0 =C2=A0 v=
oid foo(Ts... xs) requires (Regular&lt;Ts&gt;...) { } =C2=A0 // argument ty=
pes are still heterogeneous</div><div><br></div></div><div><div>=C2=A0 =C2=
=A0 template&lt;Regular... Ts&gt;</div><div>=C2=A0 =C2=A0 void foo(Ts... xs=
) { } =C2=A0 // argument types are still heterogeneous</div></div><div><br>=
</div><div><div>=C2=A0 =C2=A0 void foo(Regular... xs) { } =C2=A0 // argumen=
t types are still heterogeneous<br></div></div><div><br></div><div>HTH,</di=
v><div>=E2=80=93Arthur<br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2af4b560-8823-4ae6-b9bf-9a00fb096c84%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2af4=
b560-8823-4ae6-<wbr>b9bf-9a00fb096c84%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

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

--001a11473c6496c1870555f64afb--

.

------=_Part_1401_1544050904.1501902882108
Content-Type: multipart/alternative;
 boundary="----=_Part_1402_269772850.1501902882108"

------=_Part_1402_269772850.1501902882108
Content-Type: text/plain; charset="UTF-8"

On Friday, August 4, 2017 at 6:34:21 PM UTC-4, Bengt Gustafsson wrote:
>
> There are so many other ways to create bugs. For instance the new
> possibility:
>
> tuple(1.0, 2.0, 3.0, 40)
>
> Why can we expect people to get this right, but not auto variables.
>
> But this is not my point, but rather to make the language more consistent.
> I think that consistency means fewer rules to learn, which means that
> people tend to know more about the language and when they transfer
> knowledge from one place to another it is more likely to still be valid. In
> this case the main pain point is variadic lambdas:
>
> [](auto... xs) {}
>
> where each 'auto' means a different type. We can't change this to force it
> to mean "the same type" which is why I asked whether there was blocking
> reasons for not changing the meaning of auto variable declarations.
>
> And then, after having such lambdas included in the language it seems that
> we will get this:
>
> [](Regular... xs) {}
>
> and now all xs will be bound to the same type! Motivation: This is how
> auto variables work: duh!
>

It is my understanding that the primary motivation for this behavior is
iterator pairs: the two iterators need to be the same type. So if you're
going to use terse templates, `func(IteratorType beg, IteratorType ed)`
need to be the same type, and if the user provides different types, that's
a compile error.

Granted, Ranges TS makes a mockery of this argument by going to
Iterator/Sentinel pairs. But the Iterator thing was to my mind the primary
motivation for the thing.

Also, don't forget: right now, terse templates *don't exist* in the
standard. They didn't get added with the rest of Concepts TS.


> So my point is that as we can't reasonably have auto... in lambdas mean
> "the same type" we should investigate if we can
>
have it the other way around in all applicable places.
>

Except that `auto...` *already* doesn't mean the same thing in many other
ways.

`auto` as a variable type declaration is different from `auto` as a generic
lambda parameter. `auto` type deduction will deduce differently from
function template argument type deduction, and lambdas use the latter rules.

So there has never been an expectation that `auto...` will behave like a
multi-variable `auto` declaration.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c631d7d8-71d7-46d5-b968-c5a26a7c7d72%40isocpp.org.

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

<div dir=3D"ltr">On Friday, August 4, 2017 at 6:34:21 PM UTC-4, Bengt Gusta=
fsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">T=
here are so many other ways to create bugs. For instance the new possibilit=
y:<div><br></div><div>tuple(1.0, 2.0, 3.0, 40)</div><div><br></div><div>Why=
 can we expect people to get this right, but not auto variables.</div><div>=
<br></div><div>But this is not my point, but rather to make the language mo=
re consistent. I think that consistency means fewer rules to learn, which m=
eans that people tend to know more about the language and when they transfe=
r knowledge from one place to another it is more likely to still be valid. =
In this case the main pain point is variadic lambdas:</div><div><br></div><=
div>[](auto... xs) {}</div><div><br></div><div>where each &#39;auto&#39; me=
ans a different type. We can&#39;t change this to force it to mean &quot;th=
e same type&quot; which is why I asked whether there was blocking reasons f=
or not changing the meaning of auto variable declarations.</div><div><br></=
div><div>And then, after having such lambdas included in the language it se=
ems that we will get this:</div><div><br></div><div>[](Regular... xs) {}</d=
iv><div><br></div><div>and now all xs will be bound to the same type! Motiv=
ation: This is how auto variables work: duh!</div></div></blockquote><div><=
br>It is my understanding that the primary motivation for this behavior is =
iterator pairs: the two iterators need to be the same type. So if you&#39;r=
e going to use terse templates, `func(IteratorType beg, IteratorType ed)` n=
eed to be the same type, and if the user provides different types, that&#39=
;s a compile error.<br><br>Granted, Ranges TS makes a mockery of this argum=
ent by going to Iterator/Sentinel pairs. But the Iterator thing was to my m=
ind the primary motivation for the thing.<br><br>Also, don&#39;t forget: ri=
ght now, terse templates <i>don&#39;t exist</i> in the standard. They didn&=
#39;t get added with the rest of Concepts TS.<br>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>So my point=
 is that as we can&#39;t reasonably have auto... in lambdas mean &quot;the =
same type&quot; we should investigate if we can </div></div></blockquote><d=
iv></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=
>have it the other way around in all applicable places.</div></div></blockq=
uote><div><br>Except that `auto...` <i>already</i> doesn&#39;t mean the sam=
e thing in many other ways.<br><br>`auto` as a variable type declaration is=
 different from `auto` as a generic lambda parameter. `auto` type deduction=
 will deduce differently from function template argument type deduction, an=
d lambdas use the latter rules.<br><br>So there has never been an expectati=
on that `auto...` will behave like a multi-variable `auto` declaration.<br>=
</div></div>

<p></p>

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

------=_Part_1402_269772850.1501902882108--

------=_Part_1401_1544050904.1501902882108--

.

------=_Part_1528_1455758747.1501938005258
Content-Type: multipart/alternative;
 boundary="----=_Part_1529_1937773045.1501938005258"

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

@Arthur: As you can see from the later part of the thread there are ideas=
=20
about requiring the Regulars in the example to refer to the same type. It=
=20
was even the idea to make:

auto lambda =3D [](Regular a, Regular b) {}

require that a and b bind to the same type, motivating this by analogy to=
=20
the auto variable declarations. As Nicol pointed out this would be=20
detrimental for the Ranges TS setup which allows iterator/sentinel pairs=20
with different types to silently replace two iterators of same type.

Luckily we didn't get terse template syntax standardize in this form. Given=
=20
the objections related to Ranges TS it seems likely that a future terse=20
template syntax would allow a and b to bind to different Regulars as you=20
assumed.

I think this makes the case for changing the rule for auto variables more=
=20
compelling, along with the interpretation of structured binding:

auto[a, b] =3D { 1, 2.0 };    // ok
tuple(1, 2.0) // ok

void fun(Regular a, Regular b) {}
fun(1, 2.0);   // ok with a definition suiting Ranges TS

auto a =3D 1, b =3D 2.0;   // Currently not ok


While we didn't get terse template syntax this time I think it is likely to=
=20
crop up again, hopefully with the above more reasonable definition, to=20
improve consistency between functions and lambdas. The main argument=20
against this seems to have been that it would be too hard to see if a=20
function was a template, but I fail to see how it would be harder to see=20
the word 'auto' in a formal parameter list of a function than of a lambda.=
=20
Also with modules it would be less important to even know if a function is=
=20
a template or not as you don't have to think about seeing the=20
implementation at the point of call.

When writing the above list I was thinking that maybe these constructs=20
should be allowed, to further improve language consistency:

Regular [a, b] =3D 1, 2.0;

Regular a =3D 1, b =3D 2.0;

I don't see a parsing problem with the second variant, but the top one=20
could maybe be problematic if the compiler insists on not knowing if=20
Regular is a variable, type or concept in the parsing phase. At this point=
=20
I don't see how this could be confusing though. Apart from the consitency=
=20
aspect allowing a concept name in these positions could also improve code=
=20
clearness and maybe catch some template code errors earlier.



Den l=C3=B6rdag 5 augusti 2017 kl. 05:14:42 UTC+2 skrev Nicol Bolas:
>
> On Friday, August 4, 2017 at 6:34:21 PM UTC-4, Bengt Gustafsson wrote:
>>
>> There are so many other ways to create bugs. For instance the new=20
>> possibility:
>>
>> tuple(1.0, 2.0, 3.0, 40)
>>
>> Why can we expect people to get this right, but not auto variables.
>>
>> But this is not my point, but rather to make the language more=20
>> consistent. I think that consistency means fewer rules to learn, which=
=20
>> means that people tend to know more about the language and when they=20
>> transfer knowledge from one place to another it is more likely to still =
be=20
>> valid. In this case the main pain point is variadic lambdas:
>>
>> [](auto... xs) {}
>>
>> where each 'auto' means a different type. We can't change this to force=
=20
>> it to mean "the same type" which is why I asked whether there was blocki=
ng=20
>> reasons for not changing the meaning of auto variable declarations.
>>
>> And then, after having such lambdas included in the language it seems=20
>> that we will get this:
>>
>> [](Regular... xs) {}
>>
>> and now all xs will be bound to the same type! Motivation: This is how=
=20
>> auto variables work: duh!
>>
>
> It is my understanding that the primary motivation for this behavior is=
=20
> iterator pairs: the two iterators need to be the same type. So if you're=
=20
> going to use terse templates, `func(IteratorType beg, IteratorType ed)`=
=20
> need to be the same type, and if the user provides different types, that'=
s=20
> a compile error.
>
> Granted, Ranges TS makes a mockery of this argument by going to=20
> Iterator/Sentinel pairs. But the Iterator thing was to my mind the primar=
y=20
> motivation for the thing.
>
> Also, don't forget: right now, terse templates *don't exist* in the=20
> standard. They didn't get added with the rest of Concepts TS.
> =20
>
>> So my point is that as we can't reasonably have auto... in lambdas mean=
=20
>> "the same type" we should investigate if we can=20
>>
> have it the other way around in all applicable places.
>>
>
> Except that `auto...` *already* doesn't mean the same thing in many other=
=20
> ways.
>
> `auto` as a variable type declaration is different from `auto` as a=20
> generic lambda parameter. `auto` type deduction will deduce differently=
=20
> from function template argument type deduction, and lambdas use the latte=
r=20
> rules.
>
> So there has never been an expectation that `auto...` will behave like a=
=20
> multi-variable `auto` declaration.
>

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

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

<div dir=3D"ltr">@Arthur: As you can see from the later part of the thread =
there are ideas about requiring the Regulars in the example to refer to the=
 same type. It was even the idea to make:<div><br></div><div>auto lambda =
=3D [](Regular a, Regular b) {}</div><div><br></div><div>require that a and=
 b bind to the same type, motivating this by analogy to the auto variable d=
eclarations. As Nicol pointed out this would be detrimental for the Ranges =
TS setup which allows iterator/sentinel pairs with different types to silen=
tly replace two iterators of same type.</div><div><br></div><div>Luckily we=
 didn&#39;t get terse template syntax standardize in this form. Given the o=
bjections related to Ranges TS it seems likely that a future terse template=
 syntax would allow a and b to bind to different Regulars as you assumed.</=
div><div><br></div><div>I think this makes the case for changing the rule f=
or auto variables more compelling, along with the interpretation of structu=
red binding:</div><div><br></div><div>auto[a, b] =3D { 1, 2.0 }; =C2=A0 =C2=
=A0// ok</div><div>tuple(1, 2.0) // ok</div><div><br></div><div>void fun(Re=
gular a, Regular b) {}</div><div>fun(1, 2.0); =C2=A0 // ok with a definitio=
n suiting Ranges TS</div><div><br></div><div>auto a =3D 1, b =3D 2.0; =C2=
=A0 // Currently not ok</div><div><br></div><div><br></div><div>While we di=
dn&#39;t get terse template syntax this time I think it is likely to crop u=
p again, hopefully with the above more reasonable definition, to improve co=
nsistency between functions and lambdas. The main argument against this see=
ms to have been that it would be too hard to see if a function was a templa=
te, but I fail to see how it would be harder to see the word &#39;auto&#39;=
 in a formal parameter list of a function than of a lambda. Also with modul=
es it would be less important to even know if a function is a template or n=
ot as you don&#39;t have to think about seeing the implementation at the po=
int of call.</div><div><br></div><div>When writing the above list I was thi=
nking that maybe these constructs should be allowed, to further improve lan=
guage consistency:</div><div><br></div><div>Regular [a, b] =3D 1, 2.0;</div=
><div><br></div><div>Regular a =3D 1, b =3D 2.0;</div><div><br></div><div>I=
 don&#39;t see a parsing problem with the second variant, but the top one c=
ould maybe be problematic if the compiler insists on not knowing if Regular=
 is a variable, type or concept in the parsing phase. At this point I don&#=
39;t see how this could be confusing though. Apart from the consitency aspe=
ct allowing a concept name in these positions could also improve code clear=
ness and maybe catch some template code errors earlier.</div><div><br></div=
><div><br><br>Den l=C3=B6rdag 5 augusti 2017 kl. 05:14:42 UTC+2 skrev Nicol=
 Bolas:<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 Fri=
day, August 4, 2017 at 6:34:21 PM UTC-4, Bengt Gustafsson 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">There are so many other ways =
to create bugs. For instance the new possibility:<div><br></div><div>tuple(=
1.0, 2.0, 3.0, 40)</div><div><br></div><div>Why can we expect people to get=
 this right, but not auto variables.</div><div><br></div><div>But this is n=
ot my point, but rather to make the language more consistent. I think that =
consistency means fewer rules to learn, which means that people tend to kno=
w more about the language and when they transfer knowledge from one place t=
o another it is more likely to still be valid. In this case the main pain p=
oint is variadic lambdas:</div><div><br></div><div>[](auto... xs) {}</div><=
div><br></div><div>where each &#39;auto&#39; means a different type. We can=
&#39;t change this to force it to mean &quot;the same type&quot; which is w=
hy I asked whether there was blocking reasons for not changing the meaning =
of auto variable declarations.</div><div><br></div><div>And then, after hav=
ing such lambdas included in the language it seems that we will get this:</=
div><div><br></div><div>[](Regular... xs) {}</div><div><br></div><div>and n=
ow all xs will be bound to the same type! Motivation: This is how auto vari=
ables work: duh!</div></div></blockquote><div><br>It is my understanding th=
at the primary motivation for this behavior is iterator pairs: the two iter=
ators need to be the same type. So if you&#39;re going to use terse templat=
es, `func(IteratorType beg, IteratorType ed)` need to be the same type, and=
 if the user provides different types, that&#39;s a compile error.<br><br>G=
ranted, Ranges TS makes a mockery of this argument by going to Iterator/Sen=
tinel pairs. But the Iterator thing was to my mind the primary motivation f=
or the thing.<br><br>Also, don&#39;t forget: right now, terse templates <i>=
don&#39;t exist</i> in the standard. They didn&#39;t get added with the res=
t of Concepts TS.<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"><d=
iv dir=3D"ltr"><div></div><div>So my point is that as we can&#39;t reasonab=
ly have auto... in lambdas mean &quot;the same type&quot; we should investi=
gate if we can </div></div></blockquote><div></div><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>have it the other way around in all a=
pplicable places.</div></div></blockquote><div><br>Except that `auto...` <i=
>already</i> doesn&#39;t mean the same thing in many other ways.<br><br>`au=
to` as a variable type declaration is different from `auto` as a generic la=
mbda parameter. `auto` type deduction will deduce differently from function=
 template argument type deduction, and lambdas use the latter rules.<br><br=
>So there has never been an expectation that `auto...` will behave like a m=
ulti-variable `auto` declaration.<br></div></div></blockquote></div></div>

<p></p>

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

------=_Part_1529_1937773045.1501938005258--

------=_Part_1528_1455758747.1501938005258--

.

------=_Part_301_64878768.1501946005383
Content-Type: multipart/alternative;
 boundary="----=_Part_302_865545937.1501946005383"

------=_Part_302_865545937.1501946005383
Content-Type: text/plain; charset="UTF-8"

On Saturday, August 5, 2017 at 9:00:05 AM UTC-4, Bengt Gustafsson wrote:
>
> @Arthur: As you can see from the later part of the thread there are ideas
> about requiring the Regulars in the example to refer to the same type. It
> was even the idea to make:
>
> auto lambda = [](Regular a, Regular b) {}
>
> require that a and b bind to the same type, motivating this by analogy to
> the auto variable declarations. As Nicol pointed out this would be
> detrimental for the Ranges TS setup which allows iterator/sentinel pairs
> with different types to silently replace two iterators of same type.
>

It's not so much that it's "detrimental" to the Ranges TS; it's more that
Ranges TS means that it's not *helpful* anymore. In an iterator-pair world,
it's really convenient for `func(Iterator, Iterator)` to give a hard error
if you provide different types to those parameters. But once you leave the
iterator-pair world, that motivation goes away; in the vast majority of
remaining cases, two different uses of the same concept will want to deduce
different types.

Indeed, under Range TS iterator/sentinel pair rules, there are a number of
standard library algorithms that would be able to use the terse syntax
despite . Of particular note are the parallel algorithms, which have to
take ForwardIterators where the non-parallel version only took
OutputIterator.

Consider parallel copy, under the Range TS rules:

template< class ExecutionPolicy, class ForwardIt1, class Sentinel, class
ForwardIt2 >
ForwardIt2 copy( ExecutionPolicy&& policy, ForwardIt1 first, Sentinel last,
ForwardIt2 d_first );

Stroustrup's terse version would not be able to handle this without a
template declaration:

template<ExecutionPolicy EP, ForwardIterator FwdIt1, Sentinel Sent,
ForwardIterator FwdIt2>
FwdIt2 copy( EP&& policy, FwdIt1 first, Sent last, FwdIt2 d_first );

Template introduction syntax might make this shorter, but that's always
been a bit wonky.

With Range TS terse version, it could actually use terse syntax:

auto copy( ExecutionPolicy&& policy, ForwardIterator first, Sentinel last,
ForwardIterator d_first ) -> decltype(d_first)

So it seems to me that the number of functions that could use the terse
syntax is much greater in an iterator/sentinel world.

Luckily we didn't get terse template syntax standardize in this form. Given
> the objections related to Ranges TS it seems likely that a future terse
> template syntax would allow a and b to bind to different Regulars as you
> assumed.
>
> I think this makes the case for changing the rule for auto variables more
> compelling, along with the interpretation of structured binding:
>
> auto[a, b] = { 1, 2.0 };    // ok
> tuple(1, 2.0) // ok
>
> void fun(Regular a, Regular b) {}
> fun(1, 2.0);   // ok with a definition suiting Ranges TS
>
> auto a = 1, b = 2.0;   // Currently not ok
>
>
> While we didn't get terse template syntax this time I think it is likely
> to crop up again, hopefully with the above more reasonable definition, to
> improve consistency between functions and lambdas. The main argument
> against this seems to have been that it would be too hard to see if a
> function was a template, but I fail to see how it would be harder to see
> the word 'auto' in a formal parameter list of a function than of a lambda.
> Also with modules it would be less important to even know if a function is
> a template or not as you don't have to think about seeing the
> implementation at the point of call.
>

One of the principle reasons why it matters if a function is a template or
not is that you can't get a pointer to a template function, only to a
specific instantiation of one.

Of course, the primary reason we have to care about that is that we don't
have the ability to (easily) create lambdas that represent a function. Give
us that, and we don't have to care so much anymore.

It also should be noted that lambdas *need* brevity, since they're declared
inline. Making a regular function a bit longer by having some preceding
syntax to say it's a template is not particularly hurtful. Doing the same
to the already decidedly non-brief C++ lambda syntax only exacerbates the
problem.

The inconsistency here serves a legitimate purpose.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/46caa659-0d22-4bf4-ab03-ae97bde09bed%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, August 5, 2017 at 9:00:05 AM UTC-4, Bengt Gus=
tafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>@Arthur: As you can see from the later part of the thread there are ideas =
about requiring the Regulars in the example to refer to the same type. It w=
as even the idea to make:<div><br></div><div>auto lambda =3D [](Regular a, =
Regular b) {}</div><div><br></div><div>require that a and b bind to the sam=
e type, motivating this by analogy to the auto variable declarations. As Ni=
col pointed out this would be detrimental for the Ranges TS setup which all=
ows iterator/sentinel pairs with different types to silently replace two it=
erators of same type.</div></div></blockquote><div><br>It&#39;s not so much=
 that it&#39;s &quot;detrimental&quot; to the Ranges TS; it&#39;s more that=
 Ranges TS means that it&#39;s not <i>helpful</i> anymore. In an iterator-p=
air world, it&#39;s really convenient for `func(Iterator, Iterator)` to giv=
e a hard error if you provide different types to those parameters. But once=
 you leave the iterator-pair world, that motivation goes away; in the vast =
majority of remaining cases, two different uses of the same concept will wa=
nt to deduce different types.<br><br>Indeed, under Range TS iterator/sentin=
el pair rules, there are a number of standard library algorithms that would=
 be able to use the terse syntax despite . Of particular note are the paral=
lel algorithms, which have to take ForwardIterators where the non-parallel =
version only took OutputIterator.<br><br>Consider parallel copy, under the =
Range TS rules:<br><br><div style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; o=
verflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cl=
ass</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">ExecutionPolicy<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">ForwardIt1</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Sentinel</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">ForwardIt2</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">ForwardIt2</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> copy</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ex=
ecutionPolicy</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> policy</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: #606;" class=3D"styled-by-prettify">ForwardIt1</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> first</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: #=
606;" class=3D"styled-by-prettify">Sentinel</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">last</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
ForwardIt2</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 d_first </span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
;</span></div></code></div><br>Stroustrup&#39;s terse version would not be =
able to handle this without a template declaration:<br><br><div style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">ExecutionPolicy</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> EP</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: #606;" class=
=3D"styled-by-prettify">ForwardIterator</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">FwdIt1</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Se=
ntinel</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Sent</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">ForwardIterator</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">FwdIt2</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">FwdIt2</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> copy</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 EP</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&a=
mp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> policy=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">FwdIt1</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> first</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Sent</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">last</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: #606;" class=3D"styled-by-prettify">FwdIt2</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> d_first </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code><=
/div><br>Template introduction syntax might make this shorter, but that&#39=
;s always been a bit wonky.<br><br>With Range TS terse version, it could ac=
tually use terse syntax:<br><br><div style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> copy</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Execu=
tionPolicy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 policy</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">ForwardIterator</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> first</span><sp=
an 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=
: #606;" class=3D"styled-by-prettify">Sentinel</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">last</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">ForwardIterator</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> d_first </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">decltype</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">d_first</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>So it seems to=
 me that the number of functions that could use the terse syntax is much gr=
eater in an iterator/sentinel world.<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Luckily we didn&#39;t =
get terse template syntax standardize in this form. Given the objections re=
lated to Ranges TS it seems likely that a future terse template syntax woul=
d allow a and b to bind to different Regulars as you assumed.</div><div><br=
></div><div>I think this makes the case for changing the rule for auto vari=
ables more compelling, along with the interpretation of structured binding:=
</div><div><br></div><div>auto[a, b] =3D { 1, 2.0 }; =C2=A0 =C2=A0// ok</di=
v><div>tuple(1, 2.0) // ok</div><div><br></div><div>void fun(Regular a, Reg=
ular b) {}</div><div>fun(1, 2.0); =C2=A0 // ok with a definition suiting Ra=
nges TS</div><div><br></div><div>auto a =3D 1, b =3D 2.0; =C2=A0 // Current=
ly not ok</div><div><br></div><div><br></div><div>While we didn&#39;t get t=
erse template syntax this time I think it is likely to crop up again, hopef=
ully with the above more reasonable definition, to improve consistency betw=
een functions and lambdas. The main argument against this seems to have bee=
n that it would be too hard to see if a function was a template, but I fail=
 to see how it would be harder to see the word &#39;auto&#39; in a formal p=
arameter list of a function than of a lambda. Also with modules it would be=
 less important to even know if a function is a template or not as you don&=
#39;t have to think about seeing the implementation at the point of call.</=
div></div></blockquote><div><br>One of the principle reasons why it matters=
 if a function is a template or not is that you can&#39;t get a pointer to =
a template function, only to a specific instantiation of one.<br><br>Of cou=
rse, the primary reason we have to care about that is that we don&#39;t hav=
e the ability to (easily) create lambdas that represent a function. Give us=
 that, and we don&#39;t have to care so much anymore.<br><br>It also should=
 be noted that lambdas <i>need</i> brevity, since they&#39;re declared inli=
ne. Making a regular function a bit longer by having some preceding syntax =
to say it&#39;s a template is not particularly hurtful. Doing the same to t=
he already decidedly non-brief C++ lambda syntax only exacerbates the probl=
em.<br><br>The inconsistency here serves a legitimate purpose.<br></div></d=
iv>

<p></p>

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

------=_Part_302_865545937.1501946005383--

------=_Part_301_64878768.1501946005383--

.