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.
