All function attributes possible with "@"?

[01010100b via Digitalmars-d]

On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M Davis 
wrote:
> 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.

Actually slapping @ on all keywords would remove the 
inconsistency altogether, even if that isn't necessarily what I 
favour. Keywords which are also function attributes would seem a 
better set to allow @ on. While it is true that this reduced set 
of keywords would be "shuffling an inconsistency around" that 
still leaves open whether this inconsistency:

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

is preferable over this one:

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

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

There will always be arguments over coding style, but this isn't 
one of them, it's about language design.

> 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

Why would you need to learn pure or nothrow in addition to their 
@ counterparts?

> It's terrible for learning

No it isn't, less needs to be learned. You could think of the 
non-@ variants as deprecated.

> and it's terrible for collaboration.

No more so than deciding on a variable naming or brace style.

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

If you want to eliminate inconsistency while only paying the cost 
of breakage once, then how about this:

Let # be a character, distinct from @, such that no legal 
identifier can begin with #. Then introduce a new set of keywords 
#pure, #nogc, #const, #nothrow etc, which can be used as 
attributes. Deprecate the previous syntax. After this language 
designers can add as many #attribute keywords as they want in the 
future, since they will never clash with users' identifiers by 
definition.