On Wednesday, 14 December 2016 at 19:22:12 UTC, 01010100b wrote:
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M
Davis wrote:
On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:
So why not let all function attributes which are keywords
also be allowed to be used with a "@" prefixed?
Because it just creates yet another way to make one person's
code look drastically different from another with no real
gain? It would result in yet more style arguments without
solving anything. And it wouldn't even reduce the number of
quesions about it, because then we'd get a bunch of questions
about stuff like what the difference between pure and @pure is.
If the answer is "no difference" then I don't see the problem.
The problem is that you're _still_ getting questions about @,
which is the real problem with some attributes having it and some
not. It creates confusion. Actually learning which ones have @ or
not really isn't a big deal.
Also, would you even allow @ on stuff like static or const?
Why not?
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.
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.
I say that when dealing with the built-in attributes, just
treat @ like another letter in the keyword, learn it, and move
on.
The point is that it is easier to learn if you can just treat @
like another letter in _every_ keyword, that way you don't have
to distinguish between distinct sets of function attributes the
distinction of which is basically "historical baggage".
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, and you get additional
confusion and arguments over when @ is used or isn't. The
optional aspect of this makes it terrible aside from the fact
that it let's you do what you want with your code. It's terrible
for learning, and it's terrible for collaboration. And even if we
made the changes that you're suggesting, we'd _still_ have to
give the explanation about "historical baggage" because of the
inconsistencies that would remain.
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.
All your suggestion would really do would be to make it so that
in your own personal code, you could choose to use @ on
everything and have it consistent in that way if that's what you
prefer. It makes everything else worse.
- Jonathan M Davis
