accept @pure @nothrow @return attributes

[via Digitalmars-d]

On Wednesday, 28 January 2015 at 16:39:51 UTC, Jonathan M Davis 
wrote:
> I don't see what any of that has to do with which attributes 
> have @ on them or not.

As I said, I misinterpreted what you wrote. You came through as 
being overly defensive when it comes to accepting a syntax with 
bad usability.

It does affect both usability and marketing what the syntax looks 
like and whether the terminology is consistent with definitions. 
It sends signals about the design and the implementation that 
will be picked up by people who evaluate the language. For 
instance, the syntax of Cray's Chapel sends strong signals of the 
designers know what they are doing, so I am more inclined to give 
it a spin...

> If we could start from scratch and guarantee that no new 
> attributes would
> ever be introduced, then we could just put @ on none of them 
> and thus be
> fully consistent. But we can't start from scratch, and we can't 
> guarantee
> that there will be no new attributes.

Of course you can, but you need to get the semantics right first.

> There may be set of changes that would ultimately be better 
> enough that
> they'd be worth making - where the pros are generally 
> considered to outweigh
> the cons - but we'll be stuck with the cons regardless, and I 
> seriously
> question that any change to attribute names is enough of an 
> improvement to
> merit the code breakage that it would cause, even if it were 
> objectively
> better.

That's one viewpoint. An alternative viewpoint is that when/if D 
has reached a stable state, then it is a relatively small task 
for someone (1-2 people) to fork the language, design a new 
grammar and implement a parser for it that maps to the compiler 
internals. It is not a big project to write a new parser if the 
rest is stable.

Syntactical code breakage is not a real problem, since:

1. the D corpus is small
2. transpilers can do source-to-source compilation
3. a compiler can include multiple parsers for the same language 
semantics

Except... string mixins.