accept @pure @nothrow @return attributes

[Walter Bright via Digitalmars-d]

On 1/28/2015 1:46 PM, Jonathan Marler wrote:
> Your examples do bring up a usage I hadn't thought of though.  It would be a bit
> odd for newcomers to use "safe" without an '@' in one case and then have to
> include the '@' another case (the example you provided).  This makes it less
> appealing.  Either way, I don't think it matters since the proposal isn't
> acceptable for a different reason, the leadership doesn't like the same words to
> be used as function attributes sometimes and identifiers other times.


Good language design has redundancy in it. Often people see the redundancy, and 
advocate removing it as noise. But the redundancy has a valuable purpose - 
diagnosing of errors, and offering suggestions for fixing the errors. If there 
was no redundancy in the language, every random sequence of bytes would be a 
valid program.

For example, people often realize that the ; statement terminator is redundant, 
so they propose removing it. In trying it, however, it soon becomes clear that 
error message clarity, recovery, and the correct identification of the location 
of the error degrades substantially.

So consider:

     void func()
     safe T = 7;

With your proposal, an error isn't discovered until the '=' is found. But what 
kind of error is it? Did the user mean:

     void func() safe;
     void func() safe T;
     void func(); safe T = 7;

Even for humans it can be hard to discern what the user meant it to be, 
especially if he also is not using whitespace formatting as further redundancy.

Keywords and punctuation form "anchors" that both humans, syntax highlighters, 
and parsers use to add redundancy and "synchronization points" (which enable 
error recovery, such as "give up on the current AST and scan forward to find the 
next anchor and start afresh").