On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M Davis
wrote:
Because it's adding yet another inconsistency in the places
that don't involve function attributes. After all, static and
cost both get used in contexts where keywords such as auto and
enum get used (neither of which are function attributes), and
they don't have @. Or are you suggesting that we slap @ on all
keywords? All you're doing is shuffling inconsistencies around.
Actually slapping @ on all keywords would remove the
inconsistency altogether, even if that isn't necessarily what I
favour. Keywords which are also function attributes would seem a
better set to allow @ on. While it is true that this reduced set
of keywords would be "shuffling an inconsistency around" that
still leaves open whether this inconsistency:
final pure @nogc func()
final class G{}
is preferable over this one:
@final @pure @nogc func()
final class G{}
But even worse, you're then introducing yet another way to do
exactly the same thing in D without it adding any new
functionality. There will be questions over what the difference
between @pure and pure is. There will be questions about why
you can use both @pure and pure, but you're forced to use @safe
instead of safe. There will be yet more arguments over coding
style and whether it's better to use @pure or pure.
There will always be arguments over coding style, but this isn't
one of them, it's about language design.
Except that it isn't easier to learn, because you still have
stuff like pure and nothrow in addition to their @
counterparts, meaning that there's _more_ to learn
Why would you need to learn pure or nothrow in addition to their
@ counterparts?
It's terrible for learning
No it isn't, less needs to be learned. You could think of the
non-@ variants as deprecated.
and it's terrible for collaboration.
No more so than deciding on a variable naming or brace style.
If we could agree on a set of changes to make that made all of
this consistent, and we were willing to pay the cost of the
breakage that would result, then that would be one thing, but
optional syntax that looks like it should have a semantic
difference when it doesn't is just going to make the confusion
and questions worse, and it will add more fuel to the fire in
code style arguments.
If you want to eliminate inconsistency while only paying the cost
of breakage once, then how about this:
Let # be a character, distinct from @, such that no legal
identifier can begin with #. Then introduce a new set of keywords
#pure, #nogc, #const, #nothrow etc, which can be used as
attributes. Deprecate the previous syntax. After this language
designers can add as many #attribute keywords as they want in the
future, since they will never clash with users' identifiers by
definition.
