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

[John Colvin via Digitalmars-d]

On Sunday, 12 October 2014 at 11:24:17 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:
> On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d 
> wrote:
>> D2 is, for the most part, excellent in this respect, but it 
>> could and should be
>> even better.  Well-managed, well-documented and 
>> well-publicized breaking changes
>> in support of usability and correctness are desirable, not 
>> something to be avoided.
>
> I should add here -- I recognize the basic problem that faces 
> any language when you have newcomers (or potential corporate 
> adopters) downloading the latest compiler, downloading some 
> codebase of interest to them, and finding that it doesn't build 
> because of a backwards-incompatible change.  Even when that 
> change was 100% justified, you risk being seen as unstable, 
> untrustworthy, etc., and many people are not patient enough to 
> stick around to hear that justification.

I used to think that this was a valid point w.r.t. rejecting 
changes. Over the last year of actually trying to get work done 
in D, I've changed my tune somewhat:

At this stage, almost every release will break any project that 
has a decent sized code-base, *without considering any language 
changes or regressions*!

Fixing *any* rejects-valid or accepts-invalid bug can break 
peoples code.[1]
Adding a new symbol in phobos can break peoples code.

The only way of getting meaningful stability is to slow down a 
lot. If we're going to keep moving fast (even just fixing bugs), 
then it is unavoidable that we will break people's code. We can 
afford a little more breakage on top of the inevitable (and 
undeniably necessary) pile - even for quite minor gains - as long 
as they are changes that can be easily managed by project 
maintainers.[2]


The only argument that's left is: "I don't mind you breaking my 
code by fixing bugs in the implementation, but I do mind when 
it's for cleaning/changing the language/phobos". In light of 
recent comments from heavyweight users saying "please break my 
code in the name of improving the language and libraries", I 
don't think it holds much water.

[1] The "code that was already broken" is often dodgy. What 
constitutes broken code? There's a lot of very fragile code out 
there that is doing it's job just fine, in the limited 
circumstances it's used.

[2] By easily managed I don't mean sed-able, or even 
tooling-fixable. For me it pivots on being able to maintain one 
code-base that will compile with multiple compiler versions. An 
example where this fails: @nogc, being an attribute, isn't 
aliasable, meaning you can't version it out neatly.

#PleaseBreakMyCode but also 
#PleaseProvideScalableMeansForMeToProvideBackwardsCompatabilityToMyUsersWhoBuildMyCodeOnAVarietyOfSystemsWithAVarietyOfCompilers 
    Hmm, not so catchy :)