auto foo = calculaeFoo();
const Foo foo = calculateFoo();
const auto foo = calculateFoo();
const foo = calculateFoo(); => const auto foo = calculateFoo(); => const Foo foo = calculateFoo();const& foo = calculateFooReference(); => const auto& foo = calculateFooReference(); => const Foo& foo = calculateFooReference();
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?
auto foo = std::as_const(calculateFoo());
// C++14 generic lambdaauto 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.
On Fri, Mar 24, 2017 at 10:21 PM, Arthur O'Dwyer <arthur....@gmail.com> wrote:// C++14 generic lambdaauto 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.
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&`.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2M83vNi_rH5fdCjUUp50OLnkPCWWZdWAYfTa4Ns26B7Q%40mail.gmail.com.
const foo(bar);