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

[Don via Digitalmars-d]

On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
> On 10/9/2014 1:50 AM, Martin Nowak wrote:
>> Kenji just proposed a slightly controversial pull request so I 
>> want to reach out
>> for more people to discuss it's tradeoffs.
>> It's about deprecating function qualifiers on the left hand 
>> side of a function.
>
> This has come up before, and has been debated at length.
>
> const is used both as a storage class and as a type 
> constructor, and is distinguished by the grammar:
>
>    const(T) v; // type constructor, it affects the type T
>
>    const T v;  // storage class, affects the symbol v and the 
> type of v
>
> In particular,
>
>    const T *v;
>
> does not mean:
>
>    const(T)* v;
>
> For functions, const-as-storage-class applies to the function 
> symbol. And if it is misused, the compiler will very likely 
> complain about a mismatched type.
> Breaking this adds a special case inconsistency, besides 
> breaking existing code.
>
> (I understand that there's a lot of advocacy lately about 
> "break my code", but I'm the one who bears the brunt of "you 
> guys broke my code again, even though the code was correct and 
> worked perfectly well! D sux.", besides, of course, those poor 
> souls who have to go fix their code base, and I hear again 
> about how D is unstable, another Reddit flame-fest about D 
> being unsuitable because the designers can't make up their 
> mind, etc.)

None of those professional complainers matter though. They'll 
always find *something* to complain about.

This is an excellent example of a breaking change that pays for 
itself within weeks. A large codebase can be converted over very 
quickly, without any thought required.
It has the *immediate* benefit that the coding style improves. It 
has the longer term benefit of removing a lot of confusion.

> This endless search for the ideal syntax is consuming our time 
> while we aren't working on issues that matter. (And this change 
> will consume users' time, too, not just ours.)
>
> If we're going to break things, it needs to be for something 
> that matters. This doesn't make the cut.

No. It's a removal of one of those little friction points, that 
hurts everyone very slightly, all the time. One less thing to 
worry about, one less thing to explain, one less thing to be 
confused by.
If you have an organisation with 50 people, every one of them 
benefits slightly. In aggregate, that's a big deal.