------=_Part_679_836486516.1490296037525
Content-Type: multipart/alternative;
 boundary="----=_Part_680_1632637535.1490296037525"

------=_Part_680_1632637535.1490296037525
Content-Type: text/plain; charset=UTF-8

So, I've jumped very hard into the auto bandwagon. So much so that most of
my code now looks like:

auto foo = calculaeFoo();


It just makes it so much clearer, easier to refactor and less repetition.

However, I've found myself recanting from using const properly. I used to
have my code const correct pretty much always:

const Foo foo = calculateFoo();


But now I just cannot be bothered. I know

const auto foo = calculateFoo();


is not much longer but it just feels like cluttering the language again.

So I would like to float an idea: how about letting const imply const auto:

const foo = calculateFoo(); => const auto foo = calculateFoo(); => const
Foo foo = calculateFoo();
const& foo = calculateFooReference(); => const auto& foo =
calculateFooReference(); => const Foo& foo = calculateFooReference();


Would that work? surely I'm missing something but I wouldn't mind trying to
iron the wrinkles myself if I have some guidance and there's interest.


--
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/0ef5bc5e-575d-445a-bb63-d994d80532c3%40isocpp.org.

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

<div dir=3D"ltr">So, I&#39;ve jumped very hard into the auto bandwagon. So =
much so that most of my code now looks like:<div><br></div><blockquote styl=
e=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>auto foo =3D cal=
culaeFoo();</div></blockquote><div><br></div><div>It just makes it so much =
clearer, easier to refactor and less repetition.</div><div><br></div><div>H=
owever, I&#39;ve found myself recanting from using const properly. I used t=
o have my code const correct pretty much always:</div><div><br></div><block=
quote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>const =
Foo foo =3D calculateFoo();</div></blockquote><div><br></div><div>But now I=
 just cannot be bothered. I know=C2=A0</div><div><br></div><blockquote styl=
e=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>const auto foo =
=3D calculateFoo();</div></blockquote><div><br></div><div>is not much longe=
r but it just feels like cluttering the language again.</div><div><br></div=
><div>So I would like to float an idea: how about letting const imply const=
 auto:</div><div><br></div><blockquote style=3D"margin: 0 0 0 40px; border:=
 none; padding: 0px;"><div>const foo =3D calculateFoo(); =3D&gt; const auto=
 foo =3D calculateFoo(); =3D&gt; const Foo foo =3D calculateFoo();</div><di=
v>const&amp; foo =3D calculateFooReference(); =3D&gt; const auto&amp; foo =
=3D calculateFooReference(); =3D&gt; const Foo&amp; foo =3D calculateFooRef=
erence();</div></blockquote><div><br></div><div>Would that work? surely I&#=
39;m missing something but I wouldn&#39;t mind trying to iron the wrinkles =
myself if I have some guidance and there&#39;s interest.</div><div>=C2=A0<b=
r></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/0ef5bc5e-575d-445a-bb63-d994d80532c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ef5bc5e-575d-445a-bb63-d994d80532c3=
%40isocpp.org</a>.<br />

------=_Part_680_1632637535.1490296037525--

------=_Part_679_836486516.1490296037525--

.

------=_Part_380_455895084.1490304270606
Content-Type: text/plain; charset=UTF-8

I think there is a proposal to remove auto from the type decalation but I have not heard to much recently. What about trying to moving const on right side of the equal operator? How would that affect the code?

--
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/7250dc09-d061-4497-b215-c2b011d4efcb%40isocpp.org.

------=_Part_380_455895084.1490304270606--

.

------=_Part_1015_1986967415.1490312693261
Content-Type: multipart/alternative;
 boundary="----=_Part_1016_1467284344.1490312693261"

------=_Part_1016_1467284344.1490312693261
Content-Type: text/plain; charset=UTF-8



On Thursday, March 23, 2017 at 2:24:30 PM UTC-7, Vishal Oza wrote:
>
> I think there is a proposal to remove auto from the type decalation but I
> have not heard to much recently. What about trying to moving const on right
> side of the equal operator? How would that affect the code?


that's an interesting proposal although not sure how much would the parser
need to change to do that.

auto foo = const& calculateFooReference();

--
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/12063f8e-14fa-4c92-bb9f-dadfd63e5e6f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, March 23, 2017 at 2:24:30 PM UTC-7, V=
ishal Oza wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I think there =
is a proposal to remove auto from the type decalation but I have not heard =
to much recently. What about trying to moving const on right side of the eq=
ual operator? How would that affect the code?</blockquote><div><br></div><d=
iv>that&#39;s an interesting proposal although not sure how much would the =
parser need to change to do that.</div><div><br></div><div>auto foo =3D con=
st&amp; calculateFooReference();=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/12063f8e-14fa-4c92-bb9f-dadfd63e5e6f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/12063f8e-14fa-4c92-bb9f-dadfd63e5e6f=
%40isocpp.org</a>.<br />

------=_Part_1016_1467284344.1490312693261--

------=_Part_1015_1986967415.1490312693261--

.

On 3/23/2017 6:44 PM, Carlos Licea wrote:
> that's an interesting proposal although not sure how much would the
> parser need to change to do that.
>
> auto foo = const& calculateFooReference();

One syntactic option would be to add a form of `const` that works like a
function call and just adds const-ness to the type of its expression,
like so:

   auto foo = const(calculateFooReference());

I seem to recall a proposed feature that did something along these lines
except as a library, but I wouldn't mind seeing something like this as a
language feature.

- Jim

--
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/ob20nk%24loj%241%40blaine.gmane.org.

.

------=_Part_832_1432842925.1490327420052
Content-Type: multipart/alternative;
 boundary="----=_Part_833_183158089.1490327420052"

------=_Part_833_183158089.1490327420052
Content-Type: text/plain; charset=UTF-8



On Thursday, March 23, 2017 at 10:36:56 PM UTC-4, Jim Porter wrote:
>
> On 3/23/2017 6:44 PM, Carlos Licea wrote:
> > that's an interesting proposal although not sure how much would the
> > parser need to change to do that.
> >
> > auto foo = const& calculateFooReference();
>
> One syntactic option would be to add a form of `const` that works like a
> function call and just adds const-ness to the type of its expression,
> like so:
>
>    auto foo = const(calculateFooReference());
>
> I seem to recall a proposed feature that did something along these lines
> except as a library, but I wouldn't mind seeing something like this as a
> language feature.
>

That's `std::as_const` <http://en.cppreference.com/w/cpp/utility/as_const>.
The main downside is that if you pass it a prvalue, it can't extend the
lifetime of the temporary. Which of course is what the rvalue reference
overload is deleted.

--
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/44c205a2-aed5-47dd-abf9-9dd7fccec1e3%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, March 23, 2017 at 10:36:56 PM UTC-4, =
Jim Porter wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3/23/2017 =
6:44 PM, Carlos Licea wrote:
<br>&gt; that&#39;s an interesting proposal although not sure how much woul=
d the
<br>&gt; parser need to change to do that.
<br>&gt;
<br>&gt; auto foo =3D const&amp; calculateFooReference();
<br>
<br>One syntactic option would be to add a form of `const` that works like =
a=20
<br>function call and just adds const-ness to the type of its expression,=
=20
<br>like so:
<br>
<br>=C2=A0 =C2=A0auto foo =3D const(calculateFooReference())<wbr>;
<br>
<br>I seem to recall a proposed feature that did something along these line=
s=20
<br>except as a library, but I wouldn&#39;t mind seeing something like this=
 as a=20
<br>language feature.
<br></blockquote><div><br>That&#39;s <a href=3D"http://en.cppreference.com/=
w/cpp/utility/as_const">`std::as_const`</a>. The main downside is that if y=
ou pass it a prvalue, it can&#39;t extend the lifetime of the temporary. Wh=
ich of course is what the rvalue reference overload is  deleted.<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/44c205a2-aed5-47dd-abf9-9dd7fccec1e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44c205a2-aed5-47dd-abf9-9dd7fccec1e3=
%40isocpp.org</a>.<br />

------=_Part_833_183158089.1490327420052--

------=_Part_832_1432842925.1490327420052--

.

------=_Part_2965_480730308.1490390485159
Content-Type: multipart/alternative;
 boundary="----=_Part_2966_543919539.1490390485159"

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

On Thursday, March 23, 2017 at 12:07:17 PM UTC-7, Carlos Licea wrote:
>
> So, I've jumped very hard into the auto bandwagon. So much so that most o=
f=20
> my code now looks like:
>
> auto foo =3D calculaeFoo();
>
>
> It just makes it so much clearer, easier to refactor and less repetition.
>
> However, I've found myself recanting from using const properly. I used to=
=20
> have my code const correct pretty much always:
>
> const Foo foo =3D calculateFoo();
>
>
> But now I just cannot be bothered. I know=20
>
> const auto foo =3D calculateFoo();
>
>
> is not much longer but it just feels like cluttering the language again.
>
> So I would like to float an idea: how about letting const imply const aut=
o:
>
> const foo =3D calculateFoo(); =3D> const auto foo =3D calculateFoo(); =3D=
> const=20
> Foo foo =3D calculateFoo();
> const& foo =3D calculateFooReference(); =3D> const auto& foo =3D=20
> calculateFooReference(); =3D> const Foo& foo =3D calculateFooReference();
>
>
> Would that work? surely I'm missing something but I wouldn't mind trying=
=20
> to iron the wrinkles myself if I have some guidance and there's interest.
>

That would 100% work, grammatically; I'm confident in that because it is=20
exactly isomorphic to the old C-language rule known as "implicit int"=20
(which was removed from C in 1999).  It used to be that

main() { }

meant "int main() { }", and

static const f =3D 42;

meant "static const int f =3D 42;".  C++ preserves vestiges of "implicit in=
t"=20
in the parsing of

static signed f =3D 42;

as a synonym for "static signed int f =3D 42;", but this special behavior o=
f=20
"signed" and "unsigned" are the only cases of "implicit int still kind of=
=20
working" post-C89 as far as I know.

See=20
https://herbsutter.com/2015/04/16/reader-qa-why-was-implicit-int-removed/ =
=E2=80=94=20
notice particularly cartec69's comment, which seems to have anticipated=20
your idea two years ago! ;)  In that blog post, Herb Sutter makes the point=
=20
that if you allow implicit type names, you hamper the compiler's ability to=
=20
diagnose typos. Consider

    // C++14 generic lambda
    auto f =3D [](const bar) { return bar(); };

Today, this unambiguously means "lambda taking one parameter of type 'const=
=20
bar', unnamed, and returning a value-initialized object of type 'bar'; or,=
=20
if 'bar' is not a type, diagnose an error."
After your proposed change, this means "either the above, or, if 'bar' is=
=20
not a type, then this is a generic lambda taking one parameter of type=20
'const auto', named 'bar', and returning the result of applying operator()=
=20
to that parameter."  Either interpretation is equally valid, so the=20
compiler can't helpfully diagnose the problem if there was a problem.

We have ambiguous parses today too, of course; but it would be nice not to=
=20
*gratuitously* add more of them.

As for solutions in C++17, have you tried-and-found-wanting all of the=20
following syntaxes?
const auto foo =3D calculateFoo();
auto const foo =3D calculateFoo();
auto foo =3D std::as_const(calculateFoo());

=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/91bc38c1-cfb1-43b4-a432-742508fd7f43%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, March 23, 2017 at 12:07:17 PM UTC-7, Carlos L=
icea 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">So=
, I&#39;ve jumped very hard into the auto bandwagon. So much so that most o=
f my code now looks like:<div><br></div><blockquote style=3D"margin:0 0 0 4=
0px;border:none;padding:0px"><div>auto foo =3D calculaeFoo();</div></blockq=
uote><div><br></div><div>It just makes it so much clearer, easier to refact=
or and less repetition.</div><div><br></div><div>However, I&#39;ve found my=
self recanting from using const properly. I used to have my code const corr=
ect pretty much always:</div><div><br></div><blockquote style=3D"margin:0 0=
 0 40px;border:none;padding:0px"><div>const Foo foo =3D calculateFoo();</di=
v></blockquote><div><br></div><div>But now I just cannot be bothered. I kno=
w=C2=A0</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:n=
one;padding:0px"><div>const auto foo =3D calculateFoo();</div></blockquote>=
<div><br></div><div>is not much longer but it just feels like cluttering th=
e language again.</div><div><br></div><div>So I would like to float an idea=
: how about letting const imply const auto:</div><div><br></div><blockquote=
 style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>const foo =3D cal=
culateFoo(); =3D&gt; const auto foo =3D calculateFoo(); =3D&gt; const Foo f=
oo =3D calculateFoo();</div><div>const&amp; foo =3D calculateFooReference()=
; =3D&gt; const auto&amp; foo =3D calculateFooReference(); =3D&gt; const Fo=
o&amp; foo =3D calculateFooReference();</div></blockquote><div><br></div><d=
iv>Would that work? surely I&#39;m missing something but I wouldn&#39;t min=
d trying to iron the wrinkles myself if I have some guidance and there&#39;=
s interest.</div></div></blockquote><div><br></div><div>That would 100% wor=
k, grammatically; I&#39;m confident in that because it is exactly isomorphi=
c to the old C-language rule known as &quot;implicit int&quot; (which was r=
emoved from C in 1999). =C2=A0It used to be that</div><div><br></div><div>m=
ain() { }</div><div><br></div><div>meant &quot;int main() { }&quot;, and</d=
iv><div><br></div><div>static const f =3D 42;</div><div><br></div><div>mean=
t &quot;static const int f =3D 42;&quot;. =C2=A0C++ preserves vestiges of &=
quot;implicit int&quot; in the parsing of</div><div><br></div><div>static s=
igned f =3D 42;</div><div><br></div><div>as a synonym for &quot;static sign=
ed int f =3D 42;&quot;, but this special behavior of &quot;signed&quot; and=
 &quot;unsigned&quot; are the only cases of &quot;implicit int still kind o=
f working&quot; post-C89 as far as I know.</div><div><br></div><div>See <a =
href=3D"https://herbsutter.com/2015/04/16/reader-qa-why-was-implicit-int-re=
moved/">https://herbsutter.com/2015/04/16/reader-qa-why-was-implicit-int-re=
moved/</a> =E2=80=94 notice particularly cartec69&#39;s comment, which seem=
s to have anticipated your idea two years ago! ;) =C2=A0In that blog post, =
Herb Sutter makes the point that if you allow implicit type names, you hamp=
er the compiler&#39;s ability to diagnose typos. Consider</div><div><br></d=
iv><div>=C2=A0 =C2=A0 // C++14 generic lambda<br></div><div>=C2=A0 =C2=A0 a=
uto f =3D [](const bar) { return bar(); };</div><div><br></div><div>Today, =
this unambiguously means &quot;lambda taking one parameter of type &#39;con=
st bar&#39;, unnamed, and returning a value-initialized object of type &#39=
;bar&#39;; or, if &#39;bar&#39; is not a type, diagnose an error.&quot;</di=
v><div>After your proposed change, this means &quot;either the above, or, i=
f &#39;bar&#39; is not a type, then this is a generic lambda taking one par=
ameter of type &#39;const auto&#39;, named &#39;bar&#39;, and returning the=
 result of applying operator() to that parameter.&quot; =C2=A0Either interp=
retation is equally valid, so the compiler can&#39;t helpfully diagnose the=
 problem if there was a problem.</div><div><br></div><div>We have ambiguous=
 parses today too, of course; but it would be nice not to <i>gratuitously</=
i> add more of them.</div><div><br></div><div>As for solutions in C++17, ha=
ve you tried-and-found-wanting all of the following syntaxes?</div><div>con=
st auto foo =3D calculateFoo();</div><div>auto const foo =3D calculateFoo()=
;</div><div>auto foo =3D std::as_const(calculateFoo());</div><div><br></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/91bc38c1-cfb1-43b4-a432-742508fd7f43%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91bc38c1-cfb1-43b4-a432-742508fd7f43=
%40isocpp.org</a>.<br />

------=_Part_2966_543919539.1490390485159--

------=_Part_2965_480730308.1490390485159--

.

------=_Part_279_1383131457.1490392763782
Content-Type: multipart/alternative;
 boundary="----=_Part_280_1782581484.1490392763782"

------=_Part_280_1782581484.1490392763782
Content-Type: text/plain; charset=UTF-8



On Friday, March 24, 2017 at 5:21:25 PM UTC-4, Arthur O'Dwyer wrote:
>
> auto foo = std::as_const(calculateFoo());
>
>
 as_const doesn't do anything here. auto decays.

--
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/5f3452cd-aef7-45fd-8514-fa1ade3e9389%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, March 24, 2017 at 5:21:25 PM UTC-4, Art=
hur O&#39;Dwyer 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"><div>auto foo =3D std::as_const(calculateFoo());</div><div><br></d=
iv></div></blockquote><div><br></div><div>=C2=A0as_const doesn&#39;t do any=
thing here. auto decays.</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/5f3452cd-aef7-45fd-8514-fa1ade3e9389%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5f3452cd-aef7-45fd-8514-fa1ade3e9389=
%40isocpp.org</a>.<br />

------=_Part_280_1782581484.1490392763782--

------=_Part_279_1383131457.1490392763782--

.

------=_Part_2297_1150347860.1490394643302
Content-Type: multipart/alternative;
 boundary="----=_Part_2298_1091402471.1490394643302"

------=_Part_2298_1091402471.1490394643302
Content-Type: text/plain; charset=UTF-8

On Friday, March 24, 2017 at 5:59:23 PM UTC-4, T. C. wrote:
>
> On Friday, March 24, 2017 at 5:21:25 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> auto foo = std::as_const(calculateFoo());
>>
>>
>  as_const doesn't do anything here. auto decays.
>

Also, you'll kill any hope of elision if `calculateFoo` returns a prvalue.

In any case, none of this seems really worth it just to remove 5 keystrokes.

--
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/6981b581-d255-4b36-9271-bd8b813e28c0%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 24, 2017 at 5:59:23 PM UTC-4, T. C. wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Friday, M=
arch 24, 2017 at 5:21:25 PM UTC-4, Arthur O&#39;Dwyer wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>auto foo =3D std::as_const(c=
alculateFoo());</div><div><br></div></div></blockquote><div><br></div><div>=
=C2=A0as_const doesn&#39;t do anything here. auto decays.</div></div></bloc=
kquote><div><br>Also, you&#39;ll kill any hope of elision if `calculateFoo`=
 returns a prvalue.<br><br>In any case, none of this seems really worth it =
just to remove 5 keystrokes.<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/6981b581-d255-4b36-9271-bd8b813e28c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6981b581-d255-4b36-9271-bd8b813e28c0=
%40isocpp.org</a>.<br />

------=_Part_2298_1091402471.1490394643302--

------=_Part_2297_1150347860.1490394643302--

.

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

On Fri, Mar 24, 2017 at 10:21 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:



>     // C++14 generic lambda
>     auto f = [](const bar) { return bar(); };
>
> Today, this unambiguously means "lambda taking one parameter of type
> 'const bar', unnamed, and returning a value-initialized object of type
> 'bar'; or, if 'bar' is not a type, diagnose an error."
> After your proposed change, this means "either the above, or, if 'bar' is
> not a type, then this is a generic lambda taking one parameter of type
> 'const auto', named 'bar', and returning the result of applying operator()
> to that parameter."  Either interpretation is equally valid, so the
> compiler can't helpfully diagnose the problem if there was a problem.
>

This particular problem can be avoided by making const bar always mean
unnamed constant of type bar when in a parameter declaration, thus always
enforcing the current semantics.

Being able to define a constant type-deduced parameter would then be
impossible with that syntax, so one would have to write const auto bar
instead. I believe that is an acceptable tradeoff, because I do not think I
see a very frequent use of constant parameters passed by value, as opposed
to by reference. const &bar would mean a reference to a constant
type-deduced object in every context, so this commonly used feature would
not need to be compromised.

Also of note, here we have a certain overlap with various proposals of
abbreviated generic lambda definitions. I think we will eventually have
some of that adopted, which in my opinion is another argument in favour of
enforcing the old semantics of const bar in parameter declarations.

Cheers,
V.

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 24, 2017 at 10:21 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@=
gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0 =C2=A0 // C++14 generic=
 lambda<br></div><div>=C2=A0 =C2=A0 auto f =3D [](const bar) { return bar()=
; };</div><div><br></div><div>Today, this unambiguously means &quot;lambda =
taking one parameter of type &#39;const bar&#39;, unnamed, and returning a =
value-initialized object of type &#39;bar&#39;; or, if &#39;bar&#39; is not=
 a type, diagnose an error.&quot;</div><div>After your proposed change, thi=
s means &quot;either the above, or, if &#39;bar&#39; is not a type, then th=
is is a generic lambda taking one parameter of type &#39;const auto&#39;, n=
amed &#39;bar&#39;, and returning the result of applying operator() to that=
 parameter.&quot; =C2=A0Either interpretation is equally valid, so the comp=
iler can&#39;t helpfully diagnose the problem if there was a problem.</div>=
</div></blockquote><div><br></div><div>This particular problem can be avoid=
ed by making const bar always mean unnamed constant of type bar when in a p=
arameter declaration, thus always enforcing the current semantics.</div><di=
v><br></div><div>Being able to define a constant type-deduced parameter wou=
ld then be impossible with that syntax, so one would have to write const au=
to bar instead. I believe that is an acceptable tradeoff, because I do not =
think I see a very frequent use of constant parameters passed by value, as =
opposed to by reference. const &amp;bar would mean a reference to a constan=
t type-deduced object in every context, so this commonly used feature would=
 not need to be compromised.</div><div><br></div><div>Also of note, here we=
 have a certain overlap with various proposals of abbreviated generic lambd=
a definitions. I think we will eventually have some of that adopted, which =
in my opinion is another argument in favour of enforcing the old semantics =
of const bar in parameter declarations.</div><div><br></div><div>Cheers,</d=
iv><div>V.</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/CAA7YVg2ZKPrX3NH%3DxRSpsp6b9LNT7vquUF=
MSbGYjfoQMPH4S8w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2ZKPrX3N=
H%3DxRSpsp6b9LNT7vquUFMSbGYjfoQMPH4S8w%40mail.gmail.com</a>.<br />

--94eb2c07d34c061a10054b8e605a--

.

------=_Part_3550_241808098.1490451685497
Content-Type: multipart/alternative;
 boundary="----=_Part_3551_1646904329.1490451685497"

------=_Part_3551_1646904329.1490451685497
Content-Type: text/plain; charset=UTF-8

On Saturday, March 25, 2017 at 9:49:13 AM UTC-4, Viacheslav Usov wrote:
>
> On Fri, Mar 24, 2017 at 10:21 PM, Arthur O'Dwyer <arthur....@gmail.com
> <javascript:>> wrote:
>
>
>
>>     // C++14 generic lambda
>>     auto f = [](const bar) { return bar(); };
>>
>> Today, this unambiguously means "lambda taking one parameter of type
>> 'const bar', unnamed, and returning a value-initialized object of type
>> 'bar'; or, if 'bar' is not a type, diagnose an error."
>> After your proposed change, this means "either the above, or, if 'bar' is
>> not a type, then this is a generic lambda taking one parameter of type
>> 'const auto', named 'bar', and returning the result of applying operator()
>> to that parameter."  Either interpretation is equally valid, so the
>> compiler can't helpfully diagnose the problem if there was a problem.
>>
>
> This particular problem can be avoided by making const bar always mean
> unnamed constant of type bar when in a parameter declaration, thus always
> enforcing the current semantics.
>
> Being able to define a constant type-deduced parameter would then be
> impossible with that syntax, so one would have to write const auto bar
> instead. I believe that is an acceptable tradeoff, because I do not think I
> see a very frequent use of constant parameters passed by value, as opposed
> to by reference. const &bar would mean a reference to a constant
> type-deduced object in every context, so this commonly used feature would
> not need to be compromised.
>

So what you're saying is that you want this:

auto foo = ...; //Deduces the type.
const bar = ...; //Deduces the type, but with `const`.
const &wee = ...; //Deduces the type, as a `const&`.
[](auto foo) {}; .//Deduces the type.
[](const bar) {}; .//Unnamed parameter of type `const bar`.
[](const &wee) {}; .//Deduces the type, as a `const&`.

We should not add such inconsistencies, all just to remove 5 characters
from a line.

I'm not opposed to the idea that `&` and `&&` arguments can avoid the need
for `auto`. But `const` alone should *never* be enough to induce type
deduction.

--
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/3ce6c120-b31e-4144-9883-b71b7fea1364%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, March 25, 2017 at 9:49:13 AM UTC-4, Viachesla=
v Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Fri, Mar 24, 2017 at 10:21 PM, Arthur O&=
#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"VyQ2iCPOBgAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;java=
script:&#39;;return true;">arthur....@gmail.com</a>&gt;</span> wrote:<br><d=
iv><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>=C2=A0 =C2=A0 // C++14 generic lambda<br></div><div>=C2=A0 =C2=A0 a=
uto f =3D [](const bar) { return bar(); };</div><div><br></div><div>Today, =
this unambiguously means &quot;lambda taking one parameter of type &#39;con=
st bar&#39;, unnamed, and returning a value-initialized object of type &#39=
;bar&#39;; or, if &#39;bar&#39; is not a type, diagnose an error.&quot;</di=
v><div>After your proposed change, this means &quot;either the above, or, i=
f &#39;bar&#39; is not a type, then this is a generic lambda taking one par=
ameter of type &#39;const auto&#39;, named &#39;bar&#39;, and returning the=
 result of applying operator() to that parameter.&quot; =C2=A0Either interp=
retation is equally valid, so the compiler can&#39;t helpfully diagnose the=
 problem if there was a problem.</div></div></blockquote><div><br></div><di=
v>This particular problem can be avoided by making const bar always mean un=
named constant of type bar when in a parameter declaration, thus always enf=
orcing the current semantics.</div><div><br></div><div>Being able to define=
 a constant type-deduced parameter would then be impossible with that synta=
x, so one would have to write const auto bar instead. I believe that is an =
acceptable tradeoff, because I do not think I see a very frequent use of co=
nstant parameters passed by value, as opposed to by reference. const &amp;b=
ar would mean a reference to a constant type-deduced object in every contex=
t, so this commonly used feature would not need to be compromised.</div></d=
iv></div></div></blockquote><div><br>So what you&#39;re saying is that you =
want this:<br><br><div style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overfl=
ow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> foo </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//Deduces the type.</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> bar </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">...;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//Deduces the type, but with `const`.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">wee </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">...;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">//Deduces the type, as a `c=
onst&amp;`.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">[](</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">//Deduces the type.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[](</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{};</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">//Unnamed parameter of type `const bar`.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">wee</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #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 sty=
le=3D"color: #800;" class=3D"styled-by-prettify">//Deduces the type, as a `=
const&amp;`.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br>We should not add such inconsistencies,=
 all just to remove 5 characters from a line.<br><br>I&#39;m not opposed to=
 the idea that `&amp;` and `&amp;&amp;` arguments can avoid the need for `a=
uto`. But `const` alone should <i>never</i> be enough to induce type deduct=
ion.</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/3ce6c120-b31e-4144-9883-b71b7fea1364%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3ce6c120-b31e-4144-9883-b71b7fea1364=
%40isocpp.org</a>.<br />

------=_Part_3551_1646904329.1490451685497--

------=_Part_3550_241808098.1490451685497--

.

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

On Sat, Mar 25, 2017 at 3:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> So what you're saying is that you want this:

Yes.

> We should not add such inconsistencies, all just to remove 5 characters
from a line.

I see that differently. People being what they are, *will* save those
keystrokes, making their code more vulnerable. That is a bigger issue than
an inconsistency in a very rarely used case. And, as I said, I expect a
better way of parameter type abbreviation anyway, which makes this whole
point moot.

Cheers,
V.

--
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/CAA7YVg2M83vNi_rH5fdCjUUp50OLnkPCWWZdWAYfTa4Ns26B7Q%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 25, 2017 at 3:21 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; So what you&#39;re saying is that you want this:</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Yes.</div><div class=
=3D"gmail_quote"><div><br></div><div>&gt; We should not add such inconsiste=
ncies, all just to remove 5 characters from a line.</div><div><br></div><di=
v>I see that differently. People being what they are, <i>will</i>=C2=A0save=
 those keystrokes, making their code more vulnerable. That is a bigger issu=
e than an inconsistency in a very rarely used case. And, as I said, I expec=
t a better way of parameter type abbreviation anyway, which makes this whol=
e point moot.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br><=
/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/CAA7YVg2M83vNi_rH5fdCjUUp50OLnkPCWWZd=
WAYfTa4Ns26B7Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2M83vNi_rH=
5fdCjUUp50OLnkPCWWZdWAYfTa4Ns26B7Q%40mail.gmail.com</a>.<br />

--001a113578b4ef6c74054b8f14e0--

.

------=_Part_5140_129282022.1490565447800
Content-Type: multipart/alternative;
 boundary="----=_Part_5141_308064554.1490565447801"

------=_Part_5141_308064554.1490565447801
Content-Type: text/plain; charset=UTF-8

Certainly my poorly informed opinion is that you optimize for the common
case while leaving enough room for the uncommon case. Your proposal looks
to my a nice compromise.

Is there anything I can do to push forward this idea?

On Saturday, March 25, 2017 at 7:39:48 AM UTC-7, Viacheslav Usov wrote:
>
> On Sat, Mar 25, 2017 at 3:21 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > So what you're saying is that you want this:
>
> Yes.
>
> > We should not add such inconsistencies, all just to remove 5 characters
> from a line.
>
> I see that differently. People being what they are, *will* save those
> keystrokes, making their code more vulnerable. That is a bigger issue than
> an inconsistency in a very rarely used case. And, as I said, I expect a
> better way of parameter type abbreviation anyway, which makes this whole
> point moot.
>
> Cheers,
> V.
>
>

--
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/2035122e-51a7-4f87-9ae9-e51dd282d58c%40isocpp.org.

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

<div dir=3D"ltr">Certainly my poorly informed opinion is that you optimize =
for the common case while leaving enough room for the uncommon case. Your p=
roposal looks to my a nice compromise.<div><br></div><div>Is there anything=
 I can do to push forward this idea?</div><div><br>On Saturday, March 25, 2=
017 at 7:39:48 AM UTC-7, Viacheslav Usov wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sat, M=
ar 25, 2017 at 3:21 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"nBLgLubQBgAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&=
gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">&gt; So what you&#39;re saying is that you want this:</div><div=
 class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Yes.</div><div =
class=3D"gmail_quote"><div><br></div><div>&gt; We should not add such incon=
sistencies, all just to remove 5 characters from a line.</div><div><br></di=
v><div>I see that differently. People being what they are, <i>will</i>=C2=
=A0save those keystrokes, making their code more vulnerable. That is a bigg=
er issue than an inconsistency in a very rarely used case. And, as I said, =
I expect a better way of parameter type abbreviation anyway, which makes th=
is whole point moot.</div><div><br></div><div>Cheers,</div><div>V.</div><di=
v><br></div></div></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/2035122e-51a7-4f87-9ae9-e51dd282d58c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2035122e-51a7-4f87-9ae9-e51dd282d58c=
%40isocpp.org</a>.<br />

------=_Part_5141_308064554.1490565447801--

------=_Part_5140_129282022.1490565447800--

.

--Apple-Mail-3F88BE0A-BA07-485F-A9F6-3CD7F49AA7F6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well

There are tools that will suggest adding const and will do so on the progra=
mmers behalf (www.cevelop.com). So the keystrokes can be saved without obfu=
scating the language even more.=20

Sent from Peter Sommerlad's iPad
+41 79 432 23 32

> On 25 Mar 2017, at 15:39, Viacheslav Usov <via.usov@gmail.com> wrote:
>=20
> On Sat, Mar 25, 2017 at 3:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> > So what you're saying is that you want this:
>=20
> Yes.
>=20
> > We should not add such inconsistencies, all just to remove 5 characters=
 from a line.
>=20
> I see that differently. People being what they are, will save those keyst=
rokes, making their code more vulnerable. That is a bigger issue than an in=
consistency in a very rarely used case. And, as I said, I expect a better w=
ay of parameter type abbreviation anyway, which makes this whole point moot=
..
>=20
> Cheers,
> V.
>=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.
> 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/isoc=
pp.org/d/msgid/std-proposals/CAA7YVg2M83vNi_rH5fdCjUUp50OLnkPCWWZdWAYfTa4Ns=
26B7Q%40mail.gmail.com.

--=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/5045BDC2-6A73-4F96-9E14-B9BA9F79B6F6%40hsr.ch.

--Apple-Mail-3F88BE0A-BA07-485F-A9F6-3CD7F49AA7F6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Well</div><div id=3D"AppleMailSign=
ature"><br></div><div id=3D"AppleMailSignature">There are tools that will s=
uggest adding const and will do so on the programmers behalf (<a href=3D"ht=
tp://www.cevelop.com">www.cevelop.com</a>). So the keystrokes can be saved =
without obfuscating the language even more.&nbsp;<br><br>Sent from Peter So=
mmerlad's<span class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-co=
lor: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, =
192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.=
230469); ">&nbsp;iPad</span><div><span class=3D"Apple-style-span" style=3D"=
-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-compositio=
n-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-colo=
r: rgba(77, 128, 180, 0.230469); ">+41 79 432 23 32</span></div></div><div>=
<br>On 25 Mar 2017, at 15:39, Viacheslav Usov &lt;<a href=3D"mailto:via.uso=
v@gmail.com">via.usov@gmail.com</a>&gt; wrote:<br><br></div><blockquote typ=
e=3D"cite"><div><meta http-equiv=3D"Content-Type" content=3D"text/html; cha=
rset=3Dutf-8"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">On Sat, Mar 25, 2017 at 3:21 PM, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.=
com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">&gt; So what you're saying is that you want this:</div>=
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Yes.</div><=
div class=3D"gmail_quote"><div><br></div><div>&gt; We should not add such i=
nconsistencies, all just to remove 5 characters from a line.</div><div><br>=
</div><div>I see that differently. People being what they are, <i>will</i>&=
nbsp;save those keystrokes, making their code more vulnerable. That is a bi=
gger issue than an inconsistency in a very rarely used case. And, as I said=
, I expect a better way of parameter type abbreviation anyway, which makes =
this whole point moot.</div><div><br></div><div>Cheers,</div><div>V.</div><=
div><br></div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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/CAA7YVg2M83vNi_rH5fdCjUUp50OLnkPCWWZd=
WAYfTa4Ns26B7Q%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2M83vN=
i_rH5fdCjUUp50OLnkPCWWZdWAYfTa4Ns26B7Q%40mail.gmail.com</a>.<br>
</div></blockquote></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/5045BDC2-6A73-4F96-9E14-B9BA9F79B6F6%=
40hsr.ch?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/5045BDC2-6A73-4F96-9E14-B9BA9F79B6F6%40h=
sr.ch</a>.<br />

--Apple-Mail-3F88BE0A-BA07-485F-A9F6-3CD7F49AA7F6--

.

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

On Mon, Mar 27, 2017 at 7:48 AM, Peter Sommerlad <peter.sommerlad@hsr.ch>
wrote:

> There are tools that will suggest adding const and will do so on the
programmers behalf (www.cevelop.com). So the keystrokes can be saved
without obfuscating the language even more.

Advocating tools helping write proper C++ language as an argument against
language obfuscation? At a minimum, I'd call that non sequitur.

Cheers,
V.

--
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/CAA7YVg36Yvn%2BGCLguOmEVFJn2HhfX3zTUjCnh0LSeOFKV2TYjQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Mar 27, 2017 at 7:48 AM, Peter Sommerlad <span dir=3D"ltr">&lt;<a href=
=3D"mailto:peter.sommerlad@hsr.ch" target=3D"_blank">peter.sommerlad@hsr.ch=
</a>&gt;</span> wrote:<br><div><br></div><div>&gt; There are tools that wil=
l suggest adding const and will do so on the programmers behalf (<a href=3D=
"http://www.cevelop.com" target=3D"_blank">www.cevelop.com</a>). So the key=
strokes can be saved without obfuscating the language even more.=C2=A0</div=
><div><br></div><div>Advocating tools helping write proper C++ language as =
an argument against language obfuscation? At a minimum, I&#39;d call that n=
on sequitur.</div><div><br></div><div>Cheers,</div><div>V.</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/CAA7YVg36Yvn%2BGCLguOmEVFJn2HhfX3zTUj=
Cnh0LSeOFKV2TYjQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg36Yvn%2B=
GCLguOmEVFJn2HhfX3zTUjCnh0LSeOFKV2TYjQ%40mail.gmail.com</a>.<br />

--001a113578b4f422a7054bb29b2d--

.

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

On Sun, Mar 26, 2017 at 11:57 PM, Carlos Licea <carutsu@gmail.com> wrote:

> Is there anything I can do to push forward this idea?

This could be useful for you to read:
https://isocpp.org/std/the-life-of-an-iso-proposal

Cheers,
V.

--
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/CAA7YVg0jPdiOfj0GhdjHiYFRomkyjGx3qMCmhFWWz%2B2jK_XXGw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Mar 26, 2017 at 11:57 PM, Carlos Licea <span dir=3D"ltr">&lt;<a href=3D=
"mailto:carutsu@gmail.com" target=3D"_blank">carutsu@gmail.com</a>&gt;</spa=
n> wrote:<br><div><br></div><div>&gt; Is there anything I can do to push fo=
rward this idea?</div><div><br></div><div>This could be useful for you to r=
ead:=C2=A0<a href=3D"https://isocpp.org/std/the-life-of-an-iso-proposal">ht=
tps://isocpp.org/std/the-life-of-an-iso-proposal</a></div><div><br></div><d=
iv>Cheers,</div><div>V.</div><div><br></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/CAA7YVg0jPdiOfj0GhdjHiYFRomkyjGx3qMCm=
hFWWz%2B2jK_XXGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg0jPdiOfj=
0GhdjHiYFRomkyjGx3qMCmhFWWz%2B2jK_XXGw%40mail.gmail.com</a>.<br />

--001a113fdf62190668054bb3f564--

.

------=_Part_1628_416684101.1494221869471
Content-Type: multipart/alternative;
 boundary="----=_Part_1629_986019916.1494221869472"

------=_Part_1629_986019916.1494221869472
Content-Type: text/plain; charset=UTF-8

Will do. Thanks.

On Monday, March 27, 2017 at 3:39:28 AM UTC-7, Viacheslav Usov wrote:
>
> On Sun, Mar 26, 2017 at 11:57 PM, Carlos Licea <car...@gmail.com
> <javascript:>> wrote:
>
> > Is there anything I can do to push forward this idea?
>
> This could be useful for you to read:
> https://isocpp.org/std/the-life-of-an-iso-proposal
>
> Cheers,
> V.
>
>

--
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/2a7c9cc0-8947-443e-a2da-8b0646ac6d5a%40isocpp.org.

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

<div dir=3D"ltr">Will do. Thanks.<br><br>On Monday, March 27, 2017 at 3:39:=
28 AM UTC-7, Viacheslav Usov 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"><div><div class=3D"gmail_quote">On Sun, Mar 26, 2017=
 at 11:57 PM, Carlos Licea <span dir=3D"ltr">&lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"92QG0_FgBwAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">car...@gmail.com</a>&gt;</span>=
 wrote:<br><div><br></div><div>&gt; Is there anything I can do to push forw=
ard this idea?</div><div><br></div><div>This could be useful for you to rea=
d:=C2=A0<a href=3D"https://isocpp.org/std/the-life-of-an-iso-proposal" targ=
et=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fisocpp.org%2Fstd%2Fthe-life-of-an-iso-pro=
posal\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFJ57vBUWl3PoBWWQz4Ihe0cvvgTA&=
#39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fisocpp.org%2Fstd%2Fthe-life-of-an-iso-proposal\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFJ57vBUWl3PoBWWQz4Ihe0cvvgTA&#39;;return true=
;">https://isocpp.org/std/<wbr>the-life-of-an-iso-proposal</a></div><div><b=
r></div><div>Cheers,</div><div>V.</div><div><br></div></div></div></div>
</blockquote></div>

<p></p>

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

------=_Part_1629_986019916.1494221869472--

------=_Part_1628_416684101.1494221869471--

.

------=_Part_2656_1283510129.1494283330038
Content-Type: multipart/alternative;
 boundary="----=_Part_2657_846028693.1494283330038"

------=_Part_2657_846028693.1494283330038
Content-Type: text/plain; charset=UTF-8

One obvious issue with the syntax suggested in the OP is it creates an
ambiguous parse:

const foo(bar);

Does this declare a default-initialized variable bar of type const foo, or
does it declare a variable foo of type const
remove_reference<decltype(bar)>::type direct-initialized with bar ?

On Thursday, March 23, 2017 at 3:07:17 PM UTC-4, Carlos Licea wrote:
>
> So, I've jumped very hard into the auto bandwagon. So much so that most of
> my code now looks like:
>
> auto foo = calculaeFoo();
>
>
> It just makes it so much clearer, easier to refactor and less repetition.
>
> However, I've found myself recanting from using const properly. I used to
> have my code const correct pretty much always:
>
> const Foo foo = calculateFoo();
>
>
> But now I just cannot be bothered. I know
>
> const auto foo = calculateFoo();
>
>
> is not much longer but it just feels like cluttering the language again.
>
> So I would like to float an idea: how about letting const imply const auto:
>
> const foo = calculateFoo(); => const auto foo = calculateFoo(); => const
> Foo foo = calculateFoo();
> const& foo = calculateFooReference(); => const auto& foo =
> calculateFooReference(); => const Foo& foo = calculateFooReference();
>
>
> Would that work? surely I'm missing something but I wouldn't mind trying
> to iron the wrinkles myself if I have some guidance and there's interest.
>
>

--
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/781b1ec8-5ef8-42aa-a339-cd763c066585%40isocpp.org.

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

<div dir=3D"ltr">One obvious issue with the syntax suggested in the OP is i=
t creates an ambiguous parse:<br><br><div style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">bar</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div><br>Does this declare a default-initialized variab=
le <span style=3D"font-family: courier new,monospace;">bar</span> of type <=
font face=3D"courier new,monospace">const foo<font face=3D"arial,sans-serif=
"><font face=3D"courier new,monospace"><font face=3D"arial,sans-serif">, or=
 does it declare a variable <font face=3D"courier new,monospace">foo<font f=
ace=3D"arial,sans-serif"> of type <font face=3D"courier new,monospace">cons=
t remove_reference&lt;decltype(bar)&gt;::type<font face=3D"arial,sans-serif=
"> direct-initialized with <font face=3D"courier new,monospace">bar<font fa=
ce=3D"arial,sans-serif"> ?</font></font></font></font></font></font></font>=
</font></font></font><br><br>On Thursday, March 23, 2017 at 3:07:17 PM UTC-=
4, Carlos Licea 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">So, I&#39;ve jumped very hard into the auto bandwagon. So much so =
that most of my code now looks like:<div><br></div><blockquote style=3D"mar=
gin:0 0 0 40px;border:none;padding:0px"><div>auto foo =3D calculaeFoo();</d=
iv></blockquote><div><br></div><div>It just makes it so much clearer, easie=
r to refactor and less repetition.</div><div><br></div><div>However, I&#39;=
ve found myself recanting from using const properly. I used to have my code=
 const correct pretty much always:</div><div><br></div><blockquote style=3D=
"margin:0 0 0 40px;border:none;padding:0px"><div>const Foo foo =3D calculat=
eFoo();</div></blockquote><div><br></div><div>But now I just cannot be both=
ered. I know=C2=A0</div><div><br></div><blockquote style=3D"margin:0 0 0 40=
px;border:none;padding:0px"><div>const auto foo =3D calculateFoo();</div></=
blockquote><div><br></div><div>is not much longer but it just feels like cl=
uttering the language again.</div><div><br></div><div>So I would like to fl=
oat an idea: how about letting const imply const auto:</div><div><br></div>=
<blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>const =
foo =3D calculateFoo(); =3D&gt; const auto foo =3D calculateFoo(); =3D&gt; =
const Foo foo =3D calculateFoo();</div><div>const&amp; foo =3D calculateFoo=
Reference(); =3D&gt; const auto&amp; foo =3D calculateFooReference(); =3D&g=
t; const Foo&amp; foo =3D calculateFooReference();</div></blockquote><div><=
br></div><div>Would that work? surely I&#39;m missing something but I would=
n&#39;t mind trying to iron the wrinkles myself if I have some guidance and=
 there&#39;s interest.</div><div>=C2=A0<br></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/781b1ec8-5ef8-42aa-a339-cd763c066585%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/781b1ec8-5ef8-42aa-a339-cd763c066585=
%40isocpp.org</a>.<br />

------=_Part_2657_846028693.1494283330038--

------=_Part_2656_1283510129.1494283330038--

.

------=_Part_2586_1299092367.1494283375461
Content-Type: multipart/alternative;
 boundary="----=_Part_2587_256327001.1494283375461"

------=_Part_2587_256327001.1494283375461
Content-Type: text/plain; charset=UTF-8

One obvious issue with the syntax suggested in the OP is it creates an
ambiguous parse:

const foo(bar);

Does this declare a default-initialized variable bar of type const foo, or
does it declare a variable foo of type const
remove_reference<decltype(bar)>::type direct-initialized with bar ?

--
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/83c231be-6579-4c71-9b96-2f19465f1927%40isocpp.org.

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

<div dir=3D"ltr">One obvious issue with the syntax suggested in the OP is i=
t creates an ambiguous parse:<br><br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
"><code><div><span style=3D"color:#008">const</span><span style=3D"color:#0=
00"> foo</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">bar</span><span style=3D"color:#660">);</span><span style=3D"color:#000">=
<br></span></div></code></div><br>Does this declare a default-initialized v=
ariable <span style=3D"font-family:courier new,monospace">bar</span> of typ=
e <font face=3D"courier new,monospace">const foo<font face=3D"arial,sans-se=
rif"><font face=3D"courier new,monospace"><font face=3D"arial,sans-serif">,=
 or does it declare a variable <font face=3D"courier new,monospace">foo<fon=
t face=3D"arial,sans-serif"> of type <font face=3D"courier new,monospace">c=
onst remove_reference&lt;decltype(bar)<wbr>&gt;::type<font face=3D"arial,sa=
ns-serif"> direct-initialized with <font face=3D"courier new,monospace">bar=
<font face=3D"arial,sans-serif"> ?</font></font></font></font></font></font=
></font></font></font></font></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/83c231be-6579-4c71-9b96-2f19465f1927%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83c231be-6579-4c71-9b96-2f19465f1927=
%40isocpp.org</a>.<br />

------=_Part_2587_256327001.1494283375461--

------=_Part_2586_1299092367.1494283375461--

.

------=_Part_1291_298696814.1494365397947
Content-Type: multipart/alternative;
 boundary="----=_Part_1292_1025300926.1494365397948"

------=_Part_1292_1025300926.1494365397948
Content-Type: text/plain; charset="UTF-8"

the refness& of the auto can already be put as one entity, so why not the
constness?

cauto? autoc? constauto? ca? car? (the last one for const auto&). then we
can change auto to var and then we have var and car.

Sorry I'll stop 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/67fcfa4d-e102-4c83-bad1-ebc184dc0449%40isocpp.org.

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

<div dir=3D"ltr"><div>the refness&amp; of the auto can already be put as on=
e entity, so why not the constness?=C2=A0</div><div><br></div>cauto? autoc?=
 constauto? ca? car? (the last one for const auto&amp;). then we can change=
 auto to var and then we have var and car.=C2=A0<div><br></div><div>Sorry I=
&#39;ll stop now. :)</div><div>=C2=A0=C2=A0<br><br><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/67fcfa4d-e102-4c83-bad1-ebc184dc0449%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67fcfa4d-e102-4c83-bad1-ebc184dc0449=
%40isocpp.org</a>.<br />

------=_Part_1292_1025300926.1494365397948--

------=_Part_1291_298696814.1494365397947--

.

------=_Part_4838_855381818.1494365466105
Content-Type: multipart/alternative;
 boundary="----=_Part_4839_1094419990.1494365466105"

------=_Part_4839_1094419990.1494365466105
Content-Type: text/plain; charset="UTF-8"


the refness& of the auto can already be put as one entity, so why not the
constness?

cauto? autoc? constauto? ca? car? (the last one for const auto&). then we
can change auto to var and then we have var and car.

Sorry I'll stop 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/1947e91c-4d29-41b5-87f3-d1b216a93215%40isocpp.org.

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

<div dir=3D"ltr"><br class=3D"Apple-interchange-newline"><input type=3D"tex=
t" tabindex=3D"-1" role=3D"presentation" style=3D"height: 1px; opacity: 0; =
width: 1px; z-index: -1; overflow: hidden;"><div><div style=3D"overflow: au=
to;"><div style=3D"max-height: 10000px;"><div dir=3D"ltr"><div>the refness&=
amp; of the auto can already be put as one entity, so why not the constness=
?=C2=A0</div><div><br></div>cauto? autoc? constauto? ca? car? (the last one=
 for const auto&amp;). then we can change auto to var and then we have var =
and car.=C2=A0<div><br></div><div>Sorry I&#39;ll stop now. :)</div><div>=C2=
=A0</div></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/1947e91c-4d29-41b5-87f3-d1b216a93215%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1947e91c-4d29-41b5-87f3-d1b216a93215=
%40isocpp.org</a>.<br />

------=_Part_4839_1094419990.1494365466105--

------=_Part_4838_855381818.1494365466105--

.