All function attributes possible with "@"?

[Jonathan M Davis via Digitalmars-d]

On Thursday, 15 December 2016 at 00:08:12 UTC, 01010100b wrote:
> On Wednesday, 14 December 2016 at 20:41:57 UTC, Jonathan M 
> Davis wrote:
> 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{}

How on earth is that preferable? In the first case, every single 
attribute is always the same. In the second, sometimes they have 
@, sometimes they don't, and programmers would have to know when 
which was used. And as soon as you slap @ on attributes that 
exist in other languages, you've made D harder to learn, and 
you've made it harder to port code from other languages to D.

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

If you optionally allow @ on attributes, it definitely becomes a 
question of coding style - e.g. some code will use pure and some 
will use @pure. And you get all of the arguments over whether a 
codebase should use @ or not and whether it's acceptable to mix 
them. The only way that this does not become a coding style 
question is if we change the keywords rather than having two 
versions of them. Optional syntax pretty much always leads to 
arguments about coding style.

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

Except that they wouldn't be. It would be completely up to 
programmers to use one or the other.  So, anyone using D would 
have to be familiar with both. And _not_ having @ is what all 
existing code does and what many programmers will prefer. So, 
best case, both would be very common, and there's a decent chance 
that the @ versions would always be in the minority. Changing 
them only works if you force the change, which means _actually_ 
deprecating and removing the non-@ versions and breaking most D 
programs in the process.

>> and it's terrible for collaboration.
>
> No more so than deciding on a variable naming or brace style.

Except that we don't need to add yet another coding standard 
issue to argue over. This does _nothing_ except maybe improve 
your ability to have aesthetically pleasing code if you think 
that slapping @ on all of the attributes is aesthetically 
pleasing (and a number of folks think that the @s are downright 
ugly). Let's please not add optional syntax to the language over 
an aesthetic issue.

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

Except that most of us _don't_ want to break our code over this. 
It's not worth it. @ 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. And regardless, changing code over what attributes are 
named really dosen't add much value. Sure, it would be nice to 
not have to explain to newbies why some attributes have @ and 
some don't. Having more consistency with regards to @ would be 
nice. But at this point, it is _not_ worth breaking code over And 
I would be stunned if you could convince Walter or Andrei that it 
is. This is _exactly_ the sort of change that they think is 
detrimental to the language. It's an aesthetic issue, not a 
technical one. It doesn't cause problems beyond the fact that it 
spmetimes has to be explained to newbies, because they figure 
that the @ must mean something, when it really doesn't. And 
changing what we do with @ would arguably make the language 
_less_ visually appealing. So, it's not like we even all agree 
that such a change is even nice in principle. If we all had full 
agreement on a new syntax and that it was worth breaking our code 
over, then maybe, but you're not going to get any kind of 
consensus on what the syntax should be let alone on the change 
being worth the breakage.

- Jonathan M Davis