--000000000000376768057baee709
Content-Type: text/plain; charset="UTF-8"

The auto keyword is redundant many times.

A range for very likely begins:

"for (auto"

Function declarations, prototypes and especially lambdas with auto
parameters.

Most auto variable declarations.

Could the auto keyword be made optional? Are there cases when it would make
the language ambiguous?

Raymund Hofmann

--
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/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com.

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

<div dir=3D"auto">The auto keyword is redundant many times.<div dir=3D"auto=
"><br></div><div dir=3D"auto">A range for very likely begins:</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">&quot;for (auto&quot;</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Function declarations, prototypes and=
 especially lambdas with auto parameters.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Most auto variable declarations.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Could the auto keyword be made optional? Are the=
re cases when it would make the language ambiguous?</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Raymund Hofmann</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/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC5=
6Ubra3FcbrtzmNDw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E=
4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com</a>.<br />

--000000000000376768057baee709--

.

--Apple-Mail=_A194700B-3A06-478F-9645-AF672102583F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

If I understand what you're asking, this was proposed but was rejected:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm <http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm>

This StackOverflow post discusses it a bit:
https://stackoverflow.com/a/32706369 <https://stackoverflow.com/a/32706369>

Jared

> El nov. 27, 2018, a las 16:46, Raymund Hofmann <hofmannraymund@gmail.com>=
 escribi=C3=B3:
>=20
> The auto keyword is redundant many times.
>=20
> A range for very likely begins:
>=20
> "for (auto"
>=20
> Function declarations, prototypes and especially lambdas with auto parame=
ters.
>=20
> Most auto variable declarations.
>=20
> Could the auto keyword be made optional? Are there cases when it would ma=
ke the language ambiguous?
>=20
> Raymund Hofmann
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
 "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3Fcb=
rtzmNDw%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gm=
ail.com?utm_medium=3Demail&utm_source=3Dfooter>.

--=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/5A1317DB-205E-49B7-B641-8D1E923F0907%40gmail.com=
..

--Apple-Mail=_A194700B-3A06-478F-9645-AF672102583F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D"">If I understand what you'r=
e asking, this was proposed but was rejected:<div class=3D""><a href=3D"htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm" class=3D"">=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm</a></div>=
<div class=3D""><br class=3D""></div><div class=3D"">This StackOverflow pos=
t discusses it a bit:</div><div class=3D""><a href=3D"https://stackoverflow=
..com/a/32706369" class=3D"">https://stackoverflow.com/a/32706369</a></div><=
div class=3D""><br class=3D""></div><div class=3D"">Jared</div><div class=
=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div class=
=3D"">El nov. 27, 2018, a las 16:46, Raymund Hofmann &lt;<a href=3D"mailto:=
hofmannraymund@gmail.com" class=3D"">hofmannraymund@gmail.com</a>&gt; escri=
bi=C3=B3:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div=
 dir=3D"auto" class=3D"">The auto keyword is redundant many times.<div dir=
=3D"auto" class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">A ra=
nge for very likely begins:</div><div dir=3D"auto" class=3D""><br class=3D"=
"></div><div dir=3D"auto" class=3D"">"for (auto"</div><div dir=3D"auto" cla=
ss=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">Function declarat=
ions, prototypes and especially lambdas with auto parameters.</div><div dir=
=3D"auto" class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">Most=
 auto variable declarations.</div><div dir=3D"auto" class=3D""><br class=3D=
""></div><div dir=3D"auto" class=3D"">Could the auto keyword be made option=
al? Are there cases when it would make the language ambiguous?</div><div di=
r=3D"auto" class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">Ray=
mund Hofmann</div></div><div class=3D""><br class=3D"webkit-block-placehold=
er"></div>

-- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
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" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC5=
6Ubra3FcbrtzmNDw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" class=3D"">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/=
CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com</a>.=
<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>

<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/5A1317DB-205E-49B7-B641-8D1E923F0907%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5A1317DB-205E-49B7-B641-8D1E923F0907%=
40gmail.com</a>.<br />

--Apple-Mail=_A194700B-3A06-478F-9645-AF672102583F--

.

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

The reason on SE it was rejected seems weak for me.

The default is decltype(x) and you could prepend a &, &&, const or whatever
could be validly followed by auto.

for(&e:...)
[](const&e,i){...
auto m(&f)->...
{
  *a=3D&f;
  ...
}


Imagine a preprocessor inserting the imaginary auto and saving you from
redundancy.

Time this gets proposed again, esp. with ranges making its way into the
standard.

Auto might be remembered as the most redundant keyword.

Jared Grubb <jared.grubb@gmail.com> schrieb am Mi., 28. Nov. 2018, 09:15:

> If I understand what you're asking, this was proposed but was rejected:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
>
> This StackOverflow post discusses it a bit:
> https://stackoverflow.com/a/32706369
>
> Jared
>
> El nov. 27, 2018, a las 16:46, Raymund Hofmann <hofmannraymund@gmail.com>
> escribi=C3=B3:
>
> The auto keyword is redundant many times.
>
> A range for very likely begins:
>
> "for (auto"
>
> Function declarations, prototypes and especially lambdas with auto
> parameters.
>
> Most auto variable declarations.
>
> Could the auto keyword be made optional? Are there cases when it would
> make the language ambiguous?
>
> Raymund Hofmann
>
> --
> 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/CAD_7Vbktf7_=
A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbktf7=
_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3FcbrtzmNDw%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>
>
> --
> 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/5A1317DB-205=
E-49B7-B641-8D1E923F0907%40gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5A1317DB-20=
5E-49B7-B641-8D1E923F0907%40gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
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/CAD_7Vbko9rL-4WtiuX9%2BpJ92XF1j-t__vj-x1vhUo19B1=
fyq2Q%40mail.gmail.com.

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

<div dir=3D"auto">The reason on SE it was rejected seems weak for me.<div d=
ir=3D"auto"><br></div><div dir=3D"auto">The default is decltype(x) and you =
could prepend a &amp;, &amp;&amp;, const or whatever could be validly follo=
wed by auto.</div><div dir=3D"auto"><br></div><div dir=3D"auto">for(&amp;e:=
....)</div><div dir=3D"auto">[](const&amp;e,i){...</div><div dir=3D"auto">au=
to m(&amp;f)-&gt;...</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=A0=
 *a=3D&amp;f;</div><div dir=3D"auto">=C2=A0 ...</div><div dir=3D"auto">}</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Imagine a preprocessor inserting the imaginary auto and saving you from r=
edundancy.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Time this get=
s proposed again, esp. with ranges making its way into the standard.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Auto might be remembered as th=
e most redundant keyword.</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr">Jared Grubb &lt;<a href=3D"mailto:jared.grubb@gmail.com">jared.gr=
ubb@gmail.com</a>&gt; schrieb am Mi., 28. Nov. 2018, 09:15:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div style=3D"word-wrap:break-word;line-break:afte=
r-white-space">If I understand what you&#39;re asking, this was proposed bu=
t was rejected:<div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2014/n3853.htm" target=3D"_blank" rel=3D"noreferrer">http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm</a></div><div><br></div>=
<div>This StackOverflow post discusses it a bit:</div><div><a href=3D"https=
://stackoverflow.com/a/32706369" target=3D"_blank" rel=3D"noreferrer">https=
://stackoverflow.com/a/32706369</a></div><div><br></div><div>Jared</div><di=
v><div><br><blockquote type=3D"cite"><div>El nov. 27, 2018, a las 16:46, Ra=
ymund Hofmann &lt;<a href=3D"mailto:hofmannraymund@gmail.com" target=3D"_bl=
ank" rel=3D"noreferrer">hofmannraymund@gmail.com</a>&gt; escribi=C3=B3:</di=
v><br class=3D"m_3747879857958488514Apple-interchange-newline"><div><div di=
r=3D"auto">The auto keyword is redundant many times.<div dir=3D"auto"><br><=
/div><div dir=3D"auto">A range for very likely begins:</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">&quot;for (auto&quot;</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Function declarations, prototypes and especial=
ly lambdas with auto parameters.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Most auto variable declarations.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Could the auto keyword be made optional? Are there cases=
 when it would make the language ambiguous?</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Raymund Hofmann</div></div><div><br class=3D"m_37478798=
57958488514webkit-block-placeholder"></div>

-- <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" rel=3D"noreferrer">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" rel=3D"noreferrer">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/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC5=
6Ubra3FcbrtzmNDw%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAD_7Vbktf7_A-E4CwA4%2BkstU8gp2dQGZC56Ubra3Fcbrtz=
mNDw%40mail.gmail.com</a>.<br>
</div></blockquote></div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/5A1317DB-205E-49B7-B641-8D1E923F0907%=
40gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" r=
el=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/5A1317DB-205E-49B7-B641-8D1E923F0907%40gmail.com</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/CAD_7Vbko9rL-4WtiuX9%2BpJ92XF1j-t__vj=
-x1vhUo19B1fyq2Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbko9rL-4W=
tiuX9%2BpJ92XF1j-t__vj-x1vhUo19B1fyq2Q%40mail.gmail.com</a>.<br />

--0000000000000b4254057bb0b05c--

.

On Wed, 28 Nov 2018 at 04:54, Raymund Hofmann <hofmannraymund@gmail.com> wrote:
>
> The reason on SE it was rejected seems weak for me.

That hardly matters when two thirds of the committee opposed the proposal.

> The default is decltype(x) and you could prepend a &, &&, const or whatever could be validly followed by auto.
>
> for(&e:...)
> [](const&e,i){...
> auto m(&f)->...

The auto is not redundant in function declarations, because a function
parameter can be declared without a name.
Furthermore, with auto-type parameters, the auto keyword is the only
thing that tells you the function is
a template, and there's ample evidence that having such a syntactic
marker is something that large swaths
of the committee will insist having.

--
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/CAFk2RUao5SP_rA5Wx87e9XyfmC4j0Zv%3Dmf7rs24Z5KU5CzEa2Q%40mail.gmail.com.

.

--000000000000378631057bb14bd4
Content-Type: text/plain; charset="UTF-8"

Ville Voutilainen <ville.voutilainen@gmail.com> schrieb am Mi., 28. Nov.
2018, 10:19:

> On Wed, 28 Nov 2018 at 04:54, Raymund Hofmann <hofmannraymund@gmail.com>
> wrote:
> >
> > The reason on SE it was rejected seems weak for me.
>
> That hardly matters when two thirds of the committee opposed the proposal.
>

Changes happen all the time.


> > The default is decltype(x) and you could prepend a &, &&, const or
> whatever could be validly followed by auto.
> >
> > for(&e:...)
> > [](const&e,i){...
> > auto m(&f)->...
>
> The auto is not redundant in function declarations, because a function
> parameter can be declared without a name.
>

Then it is optional.

Furthermore, with auto-type parameters, the auto keyword is the only
> thing that tells you the function is
> a template, and there's ample evidence that having such a syntactic
> marker is something that large swaths
> of the committee will insist having.
>

A missing type doesn't tell you it is a template? Ok, it conflicts with
type only parameters of function declarations, but not for lambdas and in
class defined functions where type and name are required.
And these are the places having terse syntax options benefits the most.


> --
> 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/CAFk2RUao5SP_rA5Wx87e9XyfmC4j0Zv%3Dmf7rs24Z5KU5CzEa2Q%40mail.gmail.com
> .
>

--
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/CAD_7Vbnhye79G%2B4KUQPXNwhj4aDfRD%2B8JUi%2BO-PdSEBUnu3ZkQ%40mail.gmail.com.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.=
voutilainen@gmail.com</a>&gt; schrieb am Mi., 28. Nov. 2018, 10:19:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">On Wed, 28 Nov 2018 at 04:54, Raymund Hofm=
ann &lt;<a href=3D"mailto:hofmannraymund@gmail.com" target=3D"_blank" rel=
=3D"noreferrer">hofmannraymund@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; The reason on SE it was rejected seems weak for me.<br>
<br>
That hardly matters when two thirds of the committee opposed the proposal.<=
br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div=
></div><div dir=3D"auto">Changes happen all the time.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br>
&gt; The default is decltype(x) and you could prepend a &amp;, &amp;&amp;, =
const or whatever could be validly followed by auto.<br>
&gt;<br>
&gt; for(&amp;e:...)<br>
&gt; [](const&amp;e,i){...<br>
&gt; auto m(&amp;f)-&gt;...<br>
<br>
The auto is not redundant in function declarations, because a function<br>
parameter can be declared without a name.<br></blockquote></div></div><div =
dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"></blockquote></div></div><div dir=3D"auto">Then it =
is optional.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
Furthermore, with auto-type parameters, the auto keyword is the only<br>
thing that tells you the function is<br>
a template, and there&#39;s ample evidence that having such a syntactic<br>
marker is something that large swaths<br>
of the committee will insist having.<br></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"></blockquote></div></div><div dir=3D"auto">A missing t=
ype doesn&#39;t tell you it is a template? Ok, it conflicts with type only =
parameters of function declarations, but not for lambdas and in class defin=
ed functions where type and name are required.</div><div dir=3D"auto">And t=
hese are the places having terse syntax options benefits the most.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank" rel=3D"noreferrer">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" rel=3D"noreferrer">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/CAFk2RUao5SP_rA5Wx87e9XyfmC4j0Zv%3Dmf=
7rs24Z5KU5CzEa2Q%40mail.gmail.com" rel=3D"noreferrer noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2R=
Uao5SP_rA5Wx87e9XyfmC4j0Zv%3Dmf7rs24Z5KU5CzEa2Q%40mail.gmail.com</a>.<br>
</blockquote></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/CAD_7Vbnhye79G%2B4KUQPXNwhj4aDfRD%2B8=
JUi%2BO-PdSEBUnu3ZkQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbnhye=
79G%2B4KUQPXNwhj4aDfRD%2B8JUi%2BO-PdSEBUnu3ZkQ%40mail.gmail.com</a>.<br />

--000000000000378631057bb14bd4--

.

------=_Part_2108_1493282197.1543445913264
Content-Type: multipart/alternative;
 boundary="----=_Part_2109_1761627146.1543445913265"

------=_Part_2109_1761627146.1543445913265
Content-Type: text/plain; charset="UTF-8"

An optional "auto" would allow the following interesting code:

*int x = 10;*

*for (x : {1, 2, 3}) {} *



Does this assign to the outer "x" or declare a new, inner "x" via implicit
"auto x : ..." that shadows the outer one?

I think shadowing concerns were also among the criticisms of N3853. You can
imagine similar situations, e.g.:

*int x = 10;*
*{*
*    x = 20;   // assignment or implicit "auto x = 20;"?*
*}*


Whatever answer you come up with, you should consider how you explain that
to users, how you teach it to beginners, and how it affects code review
(where you potentially only see a single line of diff without context).

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

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

<div dir=3D"ltr">An optional &quot;auto&quot; would allow the following int=
eresting code:<div><br></div><div><blockquote style=3D"margin: 0 0 0 40px; =
border: none; padding: 0px;"><div><font face=3D"courier new, monospace"><b>=
int x =3D 10;</b></font></div></blockquote></div><blockquote style=3D"margi=
n: 0 0 0 40px; border: none; padding: 0px;"><div><div><font face=3D"courier=
 new, monospace"><b>for (x : {1, 2, 3}) {}=C2=A0</b></font></div></div></bl=
ockquote><div><blockquote style=3D"margin: 0 0 0 40px; border: none; paddin=
g: 0px;"><div><font face=3D"courier new, monospace"><b>=C2=A0</b></font></d=
iv></blockquote></div><div>Does this assign to the outer &quot;x&quot; or d=
eclare a new, inner &quot;x&quot; via implicit &quot;auto x : ...&quot; tha=
t shadows the outer one?</div><div><br></div><div>I think shadowing concern=
s were also among the criticisms of=C2=A0N3853. You can imagine similar sit=
uations, e.g.:</div><div><br></div><blockquote style=3D"margin: 0 0 0 40px;=
 border: none; padding: 0px;"><div><font face=3D"courier new, monospace"><b=
>int x =3D 10;</b></font></div><div><font face=3D"courier new, monospace"><=
b>{</b></font></div><div><font face=3D"courier new, monospace"><b>=C2=A0 =
=C2=A0 x =3D 20;=C2=A0 =C2=A0// assignment or implicit &quot;auto x =3D 20;=
&quot;?</b></font></div><div><font face=3D"courier new, monospace"><b>}</b>=
</font></div></blockquote><div><br></div><div>Whatever answer you come up w=
ith, you should consider how you explain that to users, how you teach it to=
 beginners, and how it affects code review (where you potentially only see =
a single line of diff without context).=C2=A0</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/f36089b4-cca0-47df-9527-fb73792d9cdf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f36089b4-cca0-47df-9527-fb73792d9cdf=
%40isocpp.org</a>.<br />

------=_Part_2109_1761627146.1543445913265--

------=_Part_2108_1493282197.1543445913264--

.

--00000000000009f160057bc57e30
Content-Type: text/plain; charset="UTF-8"

How is shadowing different in your examples to if there would be a type or
auto?
As i said, treat it like if there would be a imaginary auto. Seems quite
simple to me.

And with type we may get warnings and without we could too.

BTW gcc gives no shadowing warnings by default in the 2 cases with type.
It is because most intend to shadow in these cases, i think.


>

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

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

<div dir=3D"auto"><div dir=3D"auto">How is shadowing different in your exam=
ples to if there would be a type or auto?<br></div><div dir=3D"auto">As i s=
aid, treat it like if there would be a imaginary auto. Seems quite simple t=
o me.</div><div dir=3D"auto"><br></div><div dir=3D"auto">And with type we m=
ay get warnings and without we could too.<br></div><div dir=3D"auto"><br></=
div><div dir=3D"auto">BTW gcc gives no shadowing warnings by default in the=
 2 cases with type.</div><div dir=3D"auto">It is because most intend to sha=
dow in these cases, i think.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><br>
</blockquote></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/CAD_7Vbm7EAzbCTCuaqV8mA39ESCrQHbxjztB=
tQP4uCmQGO93oA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbm7EAzbCTCu=
aqV8mA39ESCrQHbxjztBtQP4uCmQGO93oA%40mail.gmail.com</a>.<br />

--00000000000009f160057bc57e30--

.

On Wed, 28 Nov 2018 at 05:38, Raymund Hofmann <hofmannraymund@gmail.com> wrote:
>> > The default is decltype(x) and you could prepend a &, &&, const or whatever could be validly followed by auto.
>> >
>> > for(&e:...)
>> > [](const&e,i){...
>> > auto m(&f)->...
>>
>> The auto is not redundant in function declarations, because a function
>> parameter can be declared without a name.
>
>
> Then it is optional.

The name is, yes. The type is not.

>> Furthermore, with auto-type parameters, the auto keyword is the only
>> thing that tells you the function is
>> a template, and there's ample evidence that having such a syntactic
>> marker is something that large swaths
>> of the committee will insist having.
> A missing type doesn't tell you it is a template?

Indeed it doesn't, because now you have to separately look up whether
the identifier is a type or not.

>Ok, it conflicts with type only parameters of function declarations, but not for lambdas and in class defined functions where type and name are required.

I don't know what "type and name are required" means there, because
the name is not required.
We did discuss the possibility of leaving out the type in lambdas in
2012, and rejected that idea.

--
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/CAFk2RUb6k%2BxoxjV07VCW6d3%2BTP4DXMWOasO3ej5ZTF0Sm3Poxw%40mail.gmail.com.

.

--0000000000002a0392057bc5d928
Content-Type: text/plain; charset="UTF-8"

And for variable declarations the optional auto is indeed questionable for
function sub-blocks, so it could only be for the top function block or
better not at all.

In class defined member functions and esp. lambda's would benefit from
optional auto in their parameter list.

Even constructors could use some kind of this to improve DRY when
initializing members.

struct a : b
{
  int i;
  const std::string s;
  struct {double d, const char *c} aa;
  a(i,s,aa,b,int n) {i+=n;}
}

It means when no type and the names match imply a member initializer list
":i(i), s(s), aa(aa),b(b)"

Raymund Hofmann <hofmannraymund@gmail.com> schrieb am Do., 29. Nov. 2018,
10:43:

> How is shadowing different in your examples to if there would be a type or
> auto?
> As i said, treat it like if there would be a imaginary auto. Seems quite
> simple to me.
>
> And with type we may get warnings and without we could too.
>
> BTW gcc gives no shadowing warnings by default in the 2 cases with type.
> It is because most intend to shadow in these cases, i think.
>
>
>>

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

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

<div dir=3D"auto">And for variable declarations the optional auto is indeed=
 questionable for function sub-blocks, so it could only be for the top func=
tion block or better not at all.<div dir=3D"auto"><br></div><div dir=3D"aut=
o">In class defined member functions and esp. lambda&#39;s would benefit fr=
om optional auto in their parameter list.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Even constructors could use some kind of this to improve =
DRY when initializing members.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">struct a : b</div><div dir=3D"auto">{</div><div dir=3D"auto">=C2=A0 =
int i;</div><div dir=3D"auto">=C2=A0 const std::string s;</div><div dir=3D"=
auto">=C2=A0 struct {double d, const char *c} aa;</div><div dir=3D"auto">=
=C2=A0 a(i,s,aa,b,int n) {i+=3Dn;}</div><div dir=3D"auto">}</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It means when no type and the names m=
atch imply a member initializer list &quot;:i(i), s(s), aa(aa),b(b)&quot;</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">Raymund Hofmann &=
lt;<a href=3D"mailto:hofmannraymund@gmail.com">hofmannraymund@gmail.com</a>=
&gt; schrieb am Do., 29. Nov. 2018, 10:43:<br></div><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"auto"><div dir=3D"auto">How is shadowing different in y=
our examples to if there would be a type or auto?<br></div><div dir=3D"auto=
">As i said, treat it like if there would be a imaginary auto. Seems quite =
simple to me.</div><div dir=3D"auto"><br></div><div dir=3D"auto">And with t=
ype we may get warnings and without we could too.<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">BTW gcc gives no shadowing warnings by defaul=
t in the 2 cases with type.</div><div dir=3D"auto">It is because most inten=
d to shadow in these cases, i think.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><br>
</blockquote></div></div></div>
</blockquote></div>

<p></p>

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

--0000000000002a0392057bc5d928--

.

--00000000000057796a057bc700d2
Content-Type: text/plain; charset="UTF-8"

Ville Voutilainen <ville.voutilainen@gmail.com> schrieb am Do., 29. Nov.
2018, 10:50:

> On Wed, 28 Nov 2018 at 05:38, Raymund Hofmann <hofmannraymund@gmail.com>
> wrote:
> >> > The default is decltype(x) and you could prepend a &, &&, const or
> whatever could be validly followed by auto.
> >> >
> >> > for(&e:...)
> >> > [](const&e,i){...
> >> > auto m(&f)->...
> >>
> >> The auto is not redundant in function declarations, because a function
> >> parameter can be declared without a name.
> >
> >
> > Then it is optional.
>
> The name is, yes. The type is not.
>

In cases where the name and type is required, the auto is optional. And
these are the most beneficial cases like lambda arguments, in class defined
member functions and constructors.


> >> Furthermore, with auto-type parameters, the auto keyword is the only
> >> thing that tells you the function is
> >> a template, and there's ample evidence that having such a syntactic
> >> marker is something that large swaths
> >> of the committee will insist having.
> > A missing type doesn't tell you it is a template?
>
> Indeed it doesn't, because now you have to separately look up whether
> the identifier is a type or not.
>

If you know that the parameter list in question is one requiring type and
name it is clear. Either type & name or "optional auto" and name.
This affords you to check if it is a function declaration or definition in
the member function / constructor case, a rather simple context check.
For lambda's it is clear, it will only improve readability.

Anyway, editors/IDE's could do the "optional auto" by displaying the code
appropriately, so the language could carry it's redundancy without lowering
readability, but still some kind of standard (a TS?) how the IDE's do it
would be good, otherwise most people will shy away from using it.

This is where most improvements in DRY, productivity, readability,
browseability and such could happen in the future anyway.

--
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/CAD_7VbnDwALER30Gv3Xktun6eu5P06eDFEkVgHo_Td%3DRw2c_Hg%40mail.gmail.com.

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">=
Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=
=3D"_blank" rel=3D"noreferrer">ville.voutilainen@gmail.com</a>&gt; schrieb =
am Do., 29. Nov. 2018, 10:50:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On We=
d, 28 Nov 2018 at 05:38, Raymund Hofmann &lt;<a href=3D"mailto:hofmannraymu=
nd@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank">hofmannraymun=
d@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; The default is decltype(x) and you could prepend a &amp;, &am=
p;&amp;, const or whatever could be validly followed by auto.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; for(&amp;e:...)<br>
&gt;&gt; &gt; [](const&amp;e,i){...<br>
&gt;&gt; &gt; auto m(&amp;f)-&gt;...<br>
&gt;&gt;<br>
&gt;&gt; The auto is not redundant in function declarations, because a func=
tion<br>
&gt;&gt; parameter can be declared without a name.<br>
&gt;<br>
&gt;<br>
&gt; Then it is optional.<br>
<br>
The name is, yes. The type is not.<br></blockquote></div></div><div dir=3D"=
auto"><br></div><div dir=3D"auto">In cases where the name and type is requi=
red, the auto is optional. And these are the most beneficial cases like lam=
bda arguments, in class defined member functions and constructors.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<br>
&gt;&gt; Furthermore, with auto-type parameters, the auto keyword is the on=
ly<br>
&gt;&gt; thing that tells you the function is<br>
&gt;&gt; a template, and there&#39;s ample evidence that having such a synt=
actic<br>
&gt;&gt; marker is something that large swaths<br>
&gt;&gt; of the committee will insist having.<br>
&gt; A missing type doesn&#39;t tell you it is a template?<br>
<br>
Indeed it doesn&#39;t, because now you have to separately look up whether<b=
r>
the identifier is a type or not.<br></blockquote></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">If you know that the parameter list in ques=
tion is one requiring type and name it is clear. Either type &amp; name or =
&quot;optional auto&quot; and name.</div><div dir=3D"auto">This affords you=
 to check if it is a function declaration or definition in the member funct=
ion / constructor case, a rather simple context check.</div><div dir=3D"aut=
o">For lambda&#39;s it is clear, it will only improve readability.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Anyway, editors/IDE&#39;s could =
do the &quot;optional auto&quot; by displaying the code appropriately, so t=
he language could carry it&#39;s redundancy without lowering readability, b=
ut still some kind of standard (a TS?) how the IDE&#39;s do it would be goo=
d, otherwise most people will shy away from using it.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">This is where most improvements in DRY, produ=
ctivity, readability, browseability and such could happen in the future any=
way.</div><div dir=3D"auto"><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/CAD_7VbnDwALER30Gv3Xktun6eu5P06eDFEkV=
gHo_Td%3DRw2c_Hg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7VbnDwALER3=
0Gv3Xktun6eu5P06eDFEkVgHo_Td%3DRw2c_Hg%40mail.gmail.com</a>.<br />

--00000000000057796a057bc700d2--

.

On Thu, 29 Nov 2018 at 07:32, Raymund Hofmann <hofmannraymund@gmail.com> wrote:
>> >> > for(&e:...)
>> >> > [](const&e,i){...
>> >> > auto m(&f)->...
>> >>
>> >> The auto is not redundant in function declarations, because a function
>> >> parameter can be declared without a name.
>> > Then it is optional.
>> The name is, yes. The type is not.
> In cases where the name and type is required, the auto is optional.

I wrote 'I don't know what "type and name are required" means there, because
the name is not required.' I still don't know what you're talking
about when you say "in cases where the name and type is required".
As far as I know, such cases do not exist.

> Anyway, editors/IDE's could do the "optional auto" by displaying the code appropriately

Such suggestions of tools showing the context haven't been convincing
before, so I doubt they would be convincing now.

--
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/CAFk2RUaUbgPQ0nH60JKF36PSR_xBJ%3DqDpRQbHC7kgQr7j_G-bA%40mail.gmail.com.

.

--000000000000c23bf0057bc8b78f
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 29, 2018 at 12:38 PM Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On Thu, 29 Nov 2018 at 07:32, Raymund Hofmann <hofmannraymund@gmail.com>
> wrote:
> > In cases where the name and type is required, the auto is optional.
>
> I wrote 'I don't know what "type and name are required" means there,
> because
> the name is not required.' I still don't know what you're talking
> about when you say "in cases where the name and type is required".
> As far as I know, such cases do not exist.
>

I thought you could only declare function parameters with a optional name,
but not define them, but you can.

Still you could apply the rule if what can not be found as a type in a
parameter declaration becomes a "optional auto" name.
Not good style to have parameter names matching user-defined type names,
anyway.

If there are unexpected ambiguities (libraries, headers, metaprogramming,
large teams), you could have a optional warning that you got the backward
compatible default which is a type name.

And new code should give a specific error on that case as soon as what is
recognized as a default parameter type is used as a instance name in the
function body, it gives a unspecific error now, it is not valid code.

void f(user_t)
{
  user_t.a=1; // <-error because user_t is a known type, did not define a
parameter
  g(user_t); // <-error because user_t is a known type, did not define a
parameter
}

You still could do:

void f(user_t user_t)
{
  user_t.a=1;
  g(user_t);
}

You could question it somewhat for functions because of that, but less for
lambda's and the range for.

This then of course depends on a lot of context to know if it is a type or
parameter name, but in times post syntax highlighting with
code-editors/IDE's it becomes viable.
And not that we are not used to overwhelming context since heavy template
use..

>
>
> Such suggestions of tools showing the context haven't been convincing
> before, so I doubt they would be convincing now.
>

Tooling is slowly moving there anyway.
Even in MSVC you now can automatically create a member function declaration
from it's definition and some more.

There are so many more tedious, error prone common tasks that you could
automate and check with tooling.

--
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/CAD_7VbnuFB%3D6KO0fRiWvty23y73VhRH40J%2B-gjjQ37L15rNqmw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, Nov 29, 2018 at 12:38 PM Ville Voutilainen &lt;<a href=3D"mailto:ville.vo=
utilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">On Thu, 29 Nov 2018 at 07:32, Raymund Hofmann =
&lt;<a href=3D"mailto:hofmannraymund@gmail.com" target=3D"_blank">hofmannra=
ymund@gmail.com</a>&gt; wrote:<br>&gt; In cases where the name and type is =
required, the auto is optional.<br>
<br>
I wrote &#39;I don&#39;t know what &quot;type and name are required&quot; m=
eans there, because<br>
the name is not required.&#39; I still don&#39;t know what you&#39;re talki=
ng<br>
about when you say &quot;in cases where the name and type is required&quot;=
..<br>
As far as I know, such cases do not exist.<br></blockquote><div><br></div><=
div>I thought you could only declare function parameters with a optional na=
me, but not define them, but you can.</div><div><br></div><div>Still you co=
uld apply the rule if what can not be found as a type in a parameter declar=
ation becomes a &quot;optional auto&quot; name.</div><div>Not good style to=
 have parameter names matching user-defined type names, anyway.</div><div><=
br></div><div>If there are unexpected ambiguities (libraries, headers, meta=
programming, large teams), you could have a optional warning that you got t=
he backward compatible default which is a type name.</div><div><br></div>An=
d new code should give a specific error on that case as soon as what is rec=
ognized as a default parameter type is used as a instance name in the funct=
ion body, it gives a unspecific error now, it is not valid code.</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">void f(user_t)</=
div><div class=3D"gmail_quote">{</div><div class=3D"gmail_quote">=C2=A0 use=
r_t.a=3D1;
 // &lt;-error because user_t is a known type, did not define a parameter

</div><div class=3D"gmail_quote">=C2=A0 g(user_t); // &lt;-error because us=
er_t is a known type, did not define a parameter<br></div><div class=3D"gma=
il_quote">}</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">You still could do:</div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">
<div class=3D"gmail_quote">void f(user_t user_t)</div><div class=3D"gmail_q=
uote">{</div><div class=3D"gmail_quote">=C2=A0=20
user_t.a=3D1;

</div><div class=3D"gmail_quote">=C2=A0 g(user_t); <br></div><div class=3D"=
gmail_quote">}</div>

</div><div class=3D"gmail_quote"><br></div>You could question it somewhat f=
or functions because of that, but less for lambda&#39;s and the range for.<=
br><div class=3D"gmail_quote"><br><div>This then of course depends on a lot=
 of context to know if it is a type or parameter name, but in times post sy=
ntax highlighting with code-editors/IDE&#39;s it becomes viable. <br></div>=
<div>And not that we are not used to overwhelming context since heavy templ=
ate use..<br></div>=C2=A0<blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Such suggestions of tools showing the context haven&#39;t been convincing<b=
r>
before, so I doubt they would be convincing now.<br></blockquote><div><br><=
/div><div>Tooling is slowly moving there anyway. <br></div><div>Even in MSV=
C you now can automatically create a member function declaration from it&#3=
9;s definition and some more.<br></div><div><br></div><div>There are so man=
y more tedious, error prone common tasks that you could automate and check =
with tooling.<br></div><div>=C2=A0</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/CAD_7VbnuFB%3D6KO0fRiWvty23y73VhRH40J=
%2B-gjjQ37L15rNqmw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7VbnuFB%3=
D6KO0fRiWvty23y73VhRH40J%2B-gjjQ37L15rNqmw%40mail.gmail.com</a>.<br />

--000000000000c23bf0057bc8b78f--

.

------=_Part_3641_623515374.1543602511420
Content-Type: multipart/alternative;
 boundary="----=_Part_3642_805093471.1543602511421"

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


2018. november 28., szerda 4:19:32 UTC+1 id=C5=91pontban Ville Voutilainen =
a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> > The reason on SE it was rejected seems weak for me.=20
>
> That hardly matters when two thirds of the committee opposed the proposal=
..=20
>  =20
>

Can you reproduce the problem example? The minutes only mention one was=20
presented, and that some suggestions floating around -- then the poll went=
=20
as massively against.=20

It's really hard to tell whether the reason is weak or strong with the key=
=20
info missing.



--=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/ea9c6664-33b8-49c9-a26c-1fa4c03cb3b5%40isocpp.or=
g.

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

<div dir=3D"ltr"><br>2018. november 28., szerda 4:19:32 UTC+1 id=C5=91pontb=
an Ville Voutilainen a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">&gt; The reason on SE it was rejected seems weak fo=
r me.
<br>
<br>That hardly matters when two thirds of the committee opposed the propos=
al.
<br>=C2=A0
<br></blockquote><div><br></div><div>Can you reproduce the problem example?=
 The minutes only mention one was presented, and that some suggestions floa=
ting around -- then the poll went as massively against. <br></div><div><br>=
</div><div>It&#39;s really hard to tell whether the reason is weak or stron=
g with the key info missing.</div><div><br></div><div><br></div><div> <br><=
/div></div>

<p></p>

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

------=_Part_3642_805093471.1543602511421--

------=_Part_3641_623515374.1543602511420--

.

--00000000000046d780057c20a2f2
Content-Type: text/plain; charset="UTF-8"

On Wed, 28 Nov 2018 at 02:54, Raymund Hofmann <hofmannraymund@gmail.com>
wrote:

> The reason on SE it was rejected seems weak for me.
>

for ( for-range-declaration : for-range-initializer ) statement

for-range-declaration:
  attribute-specifier-seq opt decl-specifier-seq declarator
  attribute-specifier-seq opt decl-specifier-seq ref-qualifier opt [
identifier-list ]

IMO it would be unreasonable to change the grammar here. Stuff like
attribute-specifier-seq are fine to make optional because they are easily
identified by the next characters ''[[" or "alignas(", those can not be
confused with decl-specifier-seq. decl-specifier-seq should not be optional
it takes more lookahead or backtracking to figure out if decl-specifier-seq
was provided or not. This is not just an issue for your compiler but any
IDE language support.

--
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/CANgTfEgkerV-21PV1goyvkU8A6AySW2yVyQK5r-APDancQr%2BBQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, 28 Nov=
 2018 at 02:54, Raymund Hofmann &lt;<a href=3D"mailto:hofmannraymund@gmail.=
com">hofmannraymund@gmail.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"auto">The reason on SE it was rejected seems weak for=
 me.<div dir=3D"auto"></div></div></blockquote><div>=C2=A0</div><div><div s=
tyle=3D"left: 385.046px; top: 135.158px;"><span style=3D"font-family:monosp=
ace,monospace"><font size=3D"1">for ( for-range-declaration : for-range-ini=
tializer ) statement</font></span></div><div style=3D"left: 385.046px; top:=
 135.158px;"><span style=3D"font-family:monospace,monospace"><font size=3D"=
1"><br></font></span></div><div style=3D"left: 385.046px; top: 135.158px;">=
<div style=3D"left: 209.425px; top: 156.024px;"><span style=3D"font-family:=
monospace,monospace"><font size=3D"1">for-range-declaration:</font></span><=
/div><div style=3D"left: 253.616px; top: 165.475px;"><span style=3D"font-fa=
mily:monospace,monospace"><font size=3D"1">=C2=A0 attribute-specifier-seq o=
pt decl-specifier-seq declarator</font></span></div><div style=3D"left: 474=
..893px; top: 182.302px;"><span style=3D"font-family:monospace,monospace"><f=
ont size=3D"1">=C2=A0 attribute-specifier-seq opt decl-specifier-seq ref-qu=
alifier opt [ identifier-list ]</font></span></div><div style=3D"left: 474.=
893px; top: 182.302px;"><span style=3D"font-family:monospace,monospace"><fo=
nt size=3D"1"><br></font></span></div><div style=3D"left: 474.893px; top: 1=
82.302px;"><span style=3D"font-family:monospace,monospace"><font size=3D"1"=
><font size=3D"2"><font face=3D"arial,helvetica,sans-serif">IMO it would be=
 unreasonable to change the grammar here. Stuff like attribute-specifier-se=
q are fine to make optional because they are easily identified by the next =
characters &#39;&#39;[[&quot; or &quot;alignas(&quot;, those can not be con=
fused with decl-specifier-seq. decl-specifier-seq should not be optional it=
 </font></font></font></span><font size=3D"2">takes more lookahead or backt=
racking to figure out if decl-specifier-seq was provided or not. This is no=
t just an issue for your compiler but any IDE language support.</font><span=
 style=3D"font-family:monospace,monospace"><font size=3D"1"><br></font></sp=
an></div><div style=3D"left: 474.893px; top: 182.302px;"><span style=3D"fon=
t-family:monospace,monospace"><font size=3D"1"><span style=3D"font-family:m=
onospace,monospace"><font size=3D"1"><span style=3D"font-family:monospace,m=
onospace"><font size=3D"1">=C2=A0 <br></font></span></font></span></font></=
span></div></div></div></div></div>

<p></p>

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

--00000000000046d780057c20a2f2--

.