All function attributes possible with "@"?

[01010100b via Digitalmars-d]

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".