On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis
wrote:
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis
wrote:
> consistent. They're
> always going to be inconsistent in one way or another, even
> if
> it's simply
> because they don't match what anyone coming from other
> languages expects
The logical conclusion from that statement would be that D
semantics are fundamentally broken...
Not really. For instance, we could make the attributes
"completely
consistent" by adding @ to all of them - @pure, @public,
@const, etc. But
that would cause inconsistencies with other languages that have
many of the
same attributes, and it would likely cause far more complaining
than the
current situation has.
We could also remove @ from all of the attributes, and then
that would be
"completely consistent," because then only UDAs will have @ on
them. But the
next time that we need to add a new attribute (which will
hopefully be rare,
but it happens sometimes - e.g. with @nogc recently), then we'd
have to add
a new keyword to avoid making things inconsistent, which would
likely break
existing code. So, more likely, we'd just tack @ onto it (which
can still
break code, but only UDA-specific code, so the breakage would
be far more
minimal), and we'd be right back where we are now.
Actually we could support removing the '@' symbol from all
attributes without making them keywords :) It would be quite
simple to do (probably a day of work in DMD, in parser.c and a
couple other places that use the code tree). At least for the
attributes on the right side of the function signature. For the
attributes on the left-hand side, it may make the syntax
ambiguous...not sure. The idea is we allow non-keyword
identifiers to be used as function attributes (on the right hand
side).
