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

[monarch_dodra via Digitalmars-d]

On Saturday, 11 October 2014 at 04:11:30 UTC, Dicebot wrote:
> On Friday, 10 October 2014 at 02:38:42 UTC, Walter Bright wrote:
>> 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;
>
> Wait what? Are you saying there is a single case when this:
>
> const T var;
>
> is not identical to this:
>
> const(T) var;

No, look at the pointer symbol.

> Reddit users are not the ones who invest into this language. If 
> this attitude won't change it is only a matter of time until 
> you start losing existing corporate users deciding to go with 
> other language or a fork instead (likely latter).
>
> I am very serious. Being a D user pretty much by definition 
> implies someone willing to risk and experiment with programming 
> tools to get a business edge. If costs of maintaing own fork 
> become lower than regular losses from maintenance overhead from 
> language quirks it becomes simple pragmatical solution. There 
> is nothing personal about it.
>
> Consistency and being robust in preventing programmer mistakes 
> is single most important feature in the long term. @nogc, C++ 
> support, any declared feature - it all means nothing with a 
> simple necessity to not waste money fighting the language.
>
> In that sense proposed change is _very_ beneficial in ROI 
> terms. It forces trivial code base adjustment that results in 
> preventing very common mistake rarely obvious for a newbies. 
> This means a very real money gains in terms of training and 
> daily mantenance overhead. Something I don't care much in a 
> personal projects but will damn appreciate as one caring for 
> success of my employer.
>
>> 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.)
>
> Hardly anything matters more than that. Issues like that 
> consume our time continiously for years, accumulating in wasted 
> days weeks of worker time. Compared with time needed to adjust 
> even several MLOC project gain is clear.

Agreed with the sentiment.

> #pleasebreakourcode

Lol.