On Wed, Aug 21, 2019 at 10:49 AM Robert Kubok via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I have a proposal referring to endless war between C++ programmers: east const vs const west. My suggestion is lead by urge to end this war and the solution is automatic type deduction for const keyword. Today we use const in many places and I'm convinced that this is one of the most used keywords in C++.
The 'const' keyword could implicitly deduce type, just as 'auto' keyword does. But as always, it's better to see an example:
This kind of syntax:
const name = std::string("Robert");

would be equivalent to:
const auto name = std::string("Robert"); // I'm a west-conster myself 😉
const std::string name("Robert");

I'd say that this idea has usability problems with constructions like

    struct Widget { Widget(const char *); ... };
    const Widget = "Robert";

Per your proposal, this would be interpreted as

    char const *const Widget = "Robert";

But is it perhaps just as likely that the user meant to define a variable of type `const Widget` and accidentally left off the variable name?
Why should leaving off the type name take priority over leaving off the variable name, especially when C++ has long allowed us to leave off parameter variable names?
What about

    auto lambda = [](const name) { ... };

Is this going to be equivalent to

    auto lambda = [](const auto name) { ... };

or to

    auto lambda = [](const name dummy) { ... };

(as it is today)?

The thing is: where 'const' keyword can be treated as 'auto' it will be, otherwise it will be treated just as if nothing changed.

In my experience, it is basically never a good idea to make a rule of the form "Try to do X, and if you find you can't, then backtrack and try Y." Because different humans will have different intuitions about how hard you ought to try before declaring that you "can't" do X. This is one of the things that makes SFINAE so subtle.