Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function

[Jonathan M Davis via Digitalmars-d]

On Friday, October 10, 2014 13:52:30 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 10/10/14 11:15 AM, Martin Nowak wrote:
> > As this is more about stating a clear preference than deprecating the
> > old syntax let me propose a compromise.
> >
> > - adding RHS rule to D's style guide http://dlang.org/dstyle.html
> >
> >    with an explanation what the storage class function thing does
> >
> > - change any dmd formatting code to RHS and change our documentation
> >
> > - leave the rest to linting tools like
> > https://github.com/Hackerpilot/Dscanner
>
> This is a case of the compiler doing the *wrong* thing when requested to
> do something else.
>
> When I say:
>
> const int
> foo() { return 1;}
>
> I mean I want foo to return a const int. The compiler does the *wrong*
> thing, and instead applies const to the hidden this parameter.
>
> In most cases, the result is a confusing error message, because most of
> the time, it won't compile. But in some cases, it will compile and do
> something completely incorrect.
>
> This is not a problem of specification, this is a problem of human
> semantics. The specification is sound, correct, and completely confusing
> to real people.
>
> To avoid the confusion, we put the const on the right side. While not
> *completely* intuitive, it's much clearer what const applies to.
>
> I think leaving this to a lint tool basically is as good and effective
> as doing nothing. It's not a compromise at all.

Agreed.

Leaving this as-is in the language has almost no benefit. The only benefit is
to avoid having to make minor changes to any code which puts the const on the
left. But there's a definite cost in confusion and developer time. We've
already been telling people for ages to put const on the right whenever it
comes up, because putting it on the left is too confusing, and questions about
it keep popping up. There is a long term cost to allowing const on the left
and only a small, short term cost to deprecating it. This is one of those
cases where focusing on not breaking code definitely costs us more than making
the change, especially when we're going to be doing via the proper deprecation
mechanism and not by just changing it and breaking existing code.

- Jonathan M Davis