All function attributes possible with "@"?

[Jonathan M Davis via Digitalmars-d]

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