On the wiki there is an argument given for why not to allow "@" on function attributes which are keywords, however it seems to include a reasoning error.

This is the argument:

"Why don't we just allow an '@' character on all function attributes so it looks consistent?

To appreciate the answer for this remember that the original problem is a matter of consistency. It's inconsistent that some function attributes use an '@' character and some don't. If D supported putting an '@' character on the function attributes that are also keywords, then this moves the inconsistency somewhere else. Since keywords are re-used all over the place, some instances of the keyword will require an '@' and some will not"

From here: https://wiki.dlang.org/Language_Designs_Explained

The error being that the "allowed" in the question is changed to "required" in the answer. Just because you would be allowed to use "@pure function()" does not imply that you are required to do so, you could still also be allowed to use "pure function()".

So why not let all function attributes which are keywords also be allowed to be used with a "@" prefixed?

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.

Also, would you even allow @ on stuff like static or const? 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.

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.

I say that when dealing with the built-in attributes, just treat @ like another letter in the keyword, learn it, and move on.

- Jonathan M Davis

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

Almost. We have other very promising options: make them context-keyword (this possibility already one of considerable solution for "body" DIP). If we introduce context-keyword then language designer are freed to add any new language defined attributes, which will be not clashed with user defined attributes, and OTOH not introduce full-blown keyword which clash with other user symbol. But as preliminary work we need probably to favour one style of context (e.g. all attributes appears after function declaration not before, there is also (possible solvable) problem how to interpret no-one function declaration `pure:` and `pure{}`).

Probably we can go even further: split the whole set of keywords into 3 subsets: full-blown keyword (like `if`, `while` etc, probably it also time to restyle `traits`), context-keywords (like mentioned attribution, probably even `private`, `public` etc can be made context-keyword, and even further `const`, `immutable` etc) but with very stric and i/e quick parse-able context, and intrinsic types (`int`, `ulong` etc, because some of them especially `real` should be made platform specific) swhich almost full-blown keyword, with only point that you not guaranteed have all of them  on your platform

On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote:
> I say that when dealing with the built-in attributes, just treat @ like another letter in the keyword, learn it, and move on.

**Applause**

This is such a small thing and it is no problem at all to get used to.  Much better to focus on things that can really make a difference.

On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton Wakeling wrote:
> On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote:
>> I say that when dealing with the built-in attributes, just treat @ like another letter in the keyword, learn it, and move on.
>
> **Applause**
>
> This is such a small thing and it is no problem at all to get used to.  Much better to focus on things that can really make a difference.

exactly the kind of logic that made c++.

if someone have to "get used" to something in the language, and there is no way to logically deduce it, the language has A HUGE PROBLEM. there just can't be more important things. 'cause it doesn't matter how much features your language has: if it require random memorization, it won't attract people. with c and c++ we haven't much choice, but now there are alot of languages.

sadly, any attempt to sanitize D is dismissing with "small thing" argument. and then we keep trying to explain why "@" in attributes is random, why `auto` is not allowed in `foreach`, and so on. and there is no real answer except "it is such a small thing! get used to it!" and that doesn't work. why newcomer have to "get used" to something right from the start, even before he developed some relations with the language?

"just get used to that small thing" is a big thing that ruins D.

On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:
> On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton Wakeling wrote:
>> On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote:
>>> I say that when dealing with the built-in attributes, just treat @ like another letter in the keyword, learn it, and move on.
>>
>> **Applause**
>>
>> This is such a small thing and it is no problem at all to get used to.  Much better to focus on things that can really make a difference.
>
> exactly the kind of logic that made c++.
>
> ...
>
> "just get used to that small thing" is a big thing that ruins D.

+1

On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote:
> On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton Wakeling wrote:
>> [...]
>
> exactly the kind of logic that made c++.
>
> [...]

This. This. This.

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

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:

>> Also, would you even allow @ on stuff like static or const?
>
> Why not?
>
Really?

>
> @pure @final @nogc func();
> @final class G{}
@@@@@@@@@@@@@@@@@@@@@@

And, "final" is not a D only thing

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