accept @pure @nothrow @return attributes

[Zach the Mystic via Digitalmars-d]

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:
> Personally, I'd much prefer that we not make this change. It's 
> just
> shuffling things around in an attempt to make them more 
> consistent while
> actually making them _less_ consistent.
>
> - Jonathan M Davis

I don't think this problem is solvable without "dfix". Here are 
the factors I would consider:

1. `@` is ugly. Therefore it would be great to make `safe`, 
`trusted`, `system`, and `nogc` full-fledged keywords, to spare 
future readers of code all those `@`s.  So long as it's 
definitely a permanent feature of the language, it should look as 
good as possible. (`property` too, if we're sure it's not 
leaving). `@` is then left exclusively for UDAs, an improvement, 
IMO.

2. Consistency of attribute usage is important. All built-in 
attributes should be markable in the same way, either with, or 
without an `@` sign.

3. Singularity of usage also matters. There should only be one 
way to mark a given attribute, either with or without `@`.

4. Old code matters. Existing code puts points 2 and 3 into 
conflict.

Now it goes without saying that changing old code is a nuisance. 
But it's important to point out that not all code changes are the 
same. In the interest of furthering this discussion, here is a 
list of the types of breaking changes, in my order of least to 
most desirable:

B1. Silent breaking changes. Same code now does different things. 
Rightly regarded as the worst kind. You don't even know what hit 
you.

B2. Completely pointless changes. For the record, I'm against 
changes which literally have no benefit. Most changes which get 
seriously discussed, however, involve difficult tradeoffs, for 
which the assumed benefit must outweigh the perceived loss, plus 
the "switching costs". The point of this list is to emphasize 
that not all switching costs are the same, and that they depend 
greatly on the *individual* change.

B3. Breaking changes which require significant redesign of code. 
Sociomantic faces this issue with their move to D2.

B4. Changes which can easily be fixed, with the right know-how. 
Great error messages, referring the user to the documentation of 
these changes and how to fix them, is essential.

B5. The kind that a tool such as 'dfix', can automate. For 
example, let's say dfix is included with the compiler package. 
Now you get an error, saying: "Error: `@nogc` is no longer 
accepted, but can be automatically replaced with `nogc`. Run dfix 
on this file? (y/n)"... or whatever is deemed the secure approach 
to this feature.

B6. Changes which catch existing bugs, with no false positives. 
Obviously wins.


The changes suggested in this thread are of kind 5.5. But more 
people would have to get behind the whole 'dfix' approach for it 
to work.

"Most D code is yet to be written. #PleaseBreakOurCode." +1