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.
Also, would you even allow @ on stuff like static or const?
Why not?
Those can be used elsewhere in places where nothing has @ on
it, creating yet more inconsistencies if you allowed it in
those places, and if you allowed @ when they were used on
functions and not elsewhere, that's yet another inconsistency.
That may be so, but why should I prefer this inconsistency:
pure final @nogc func();
final class G{}
over this one? :
@pure @final @nogc func();
final class G{}
Also, allowing keywords to be written with "@" prefixed would
allow consistent use as well, such as
@pure @final @nogc func();
@final class G{}
Right now we are locked into a certain inconsistency, at least
with the proposed change we'd be able to construct one ourselves
should we want to do so.
The _only_ way to eliminate all of the inconsistencies with @
is to get rid of it from everywhere but UDAs, and turn all of
those built-in attributes into full-blown keywords, and we're
simply not going to do that. Any other solution is just moving
the inconsistencies around.
That is false, you can clearly also remove all inconsistencies by
getting rid of full-blown keywords as function attributes and
turn all of them into built-in attributes. Much less likely to
break existing code as well.
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".
