On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis wrote:
> How on earth is that preferable?

Sorry, forgot to actually answer your question. It is preferable since it is implied by a simple rule (function attributes go with @) rather than rote learning of effectively random historical data.

But even if you don't think that's preferable, there's still a difference between having a different preference and having one preference actually being enforced by the language. In terms of coding style, nobody expects a language to enforce a certain variable naming convention either.

And this particular change would probably not incur any breakage of existing code, unless people happen to be using UDAs with the same name as function attribute keywords. It would also, if absolute lack of inconsistency is your only determinant, allow for this:

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

which does fit your stated requirement.

On Thursday, 15 December 2016 at 03:56:56 UTC, Jonathan M Davis wrote:
> @ is ugly. # is ugly. Both add unecessary characters. Aesthetically speaking, it would be _way_ better ts have them all be keywords, but we didn't want to have that many keywords.
>
> - Jonathan M Davis

I agree with the @ is ugly and # is ugly, but I believe @safe, @nogc and @property should have been keywords.

A personal opinion of mine though is that @safe shouldn't have existed and should have been the default for functions, where a @unsafe should have existed in its place.

That's a design choice ex. Rust does better than D. It provides safety by default, where in D you have to enable safety.

On Thursday, 15 December 2016 at 06:40:06 UTC, 01010100b wrote:
> And if the goal is greater adoption of the language then I don't think it's true that only technical changes matter. Going by the, admittedly small, sample of myself the problem is not not being able to learn which attributes to write with @, but that this just screams "bad design!" at me. Which then leads me to wonder "if I invest more into learning and experimenting with this language to see if it can solve the problem I want it to solve, how likely will it be that I will run into more such things which then eventually lead me to reject the language in favour of another alternative, thereby wasting my investment in it?"

hear, hear! this is what i am screaming about all the time: requiring each newcomer to perform leap of faith even before he felt in love with D! ;-)

btw, i'm using D exclusively for all my programming tasks (including scripts i used to write in sh ;-) for several years now, and i still have to stop and thing where to put that "@" sometimes. 'cause it is impossible to deduce, and i am very bad in memorizing arbitrary non-logical things.

On Thursday, 15 December 2016 at 07:13:18 UTC, 01010100b wrote:
> And this particular change would probably not incur any breakage of existing code, unless people happen to be using UDAs with the same name as function attribute keywords.

...which is impossible, 'cause keyword can be used as identifier.

On Thursday, 15 December 2016 at 10:50:39 UTC, ketmar wrote:
> On Thursday, 15 December 2016 at 07:13:18 UTC, 01010100b wrote:
>> And this particular change would probably not incur any breakage of existing code, unless people happen to be using UDAs with the same name as function attribute keywords.
>
> ...which is impossible, 'cause keyword can be used as identifier.

CAN'T, of course. sorry.

On Thursday, 15 December 2016 at 08:48:10 UTC, Bauss wrote:
>
> I agree with the @ is ugly and # is ugly, but I believe @safe, @nogc and @property should have been keywords.
>

Sometimes I like to imagine I could get in a time machine and make things better.

But in the real world, I more and more prefer to focus on the important things.

On Thursday, 15 December 2016 at 10:50:39 UTC, ketmar wrote:
> On Thursday, 15 December 2016 at 07:13:18 UTC, 01010100b wrote:
>> And this particular change would probably not incur any breakage of existing code, unless people happen to be using UDAs with the same name as function attribute keywords.
>
> ...which is impossible, 'cause keyword can be used as identifier.

Ah yes, true. Then we have

1. Allow @ on all function attribute keywords.
2. Allow @ on all keywords.

Neither of these is a breaking change, however future attributes which might get added will be a breaking change each.

And we have

3. Remove the @ and make keywords like nogc etc.
4. Add a set of strings of "language defined attributes" prefixed by # and put the existing ones in there.

Both of these are breaking. 3. is the "prettiest" but would give huge issues with possible future attributes. 4. is the most general and future-looking, so that future attributes will never require a breaking change.

On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:
> 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.

Related DIP: https://wiki.dlang.org/DIP64