On Wed, Aug 21, 2019 at 10:49 AM Robert Kubok via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
> 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.

–Arthur