accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic 
wrote:
> On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler 
> wrote:
>> Haha, ok, sorry for being too abstract.
>>
>> I think a safe way to implement my proposal would be to do 
>> what c++ did and only allow non-keyword function attributes to 
>> omit the '@' symbol if they appear after the function 
>> signature:
>>
>> Here's what would change
>> -----------------------------------------------------------------
>> void myfunc() nogc; // VALID (Only if this proposal is 
>> accepted)
>> void myfunc() safe; // VALID (Only if this proposal is 
>> accepted)
>>
>>
>> Here's what WOULD NOT change
>> -----------------------------------------------------------------
>> nogc myfunc(); // STILL INVALID: invalid unless it can be 
>> verified
>>               //          that this wouldn't result in 
>> ambiguity
>>               //          in the grammar
>> void myfunc() @nogc; // STILL VALID (no change)
>> @nogc myfunc(); // STILL VALID (no change)
>>
>> If the initial proposal is accepted by people, then we can 
>> talk about the other examples, but let's focus on the proposal 
>> before focusing on sub-proposals.
>
> Alright, good. However... I'm still against it. Firstly, in my 
> first comment in the current thread,
>
> http://forum.dlang.org/post/uimpnhiweuitnnbeqshu@forum.dlang.org
>
> ...I made a list of considerations, among which:
>
> 3. Singularity of usage also matters. There should only be one
> way to mark a given attribute, either with or without `@`.
>
> This alone puts me at next to zero for your proposal in terms 
> of benefit. It will strike people as a strange and unnecessary 
> exception to the way to mark their attributes, for the sake of 
> a slight beautification of only those cases where the 
> attributes come after the signature. Consider me an 
> old-fashioned "a keyword is a keyword is a keyword" kind of 
> guy. Yes, there are outliers (C++, D, exit, success, etc.), but 
> I don't see why that list should be expanded, as it is nicely 
> contained, IMO.

I agree that the proposal doesn't solve the consistency issue, 
but the proposal doesn't make things more inconsistent then they 
already are. It adds another way to write these attributes, but 
it adds a way that makes more sense in my opinion.  This is a 
step in the right direction in solving the problem.  The next 
step would be to solve the consistency issue, but again, that's 
another debate. To conclude, which code would you rather write?

void myfunc() pure @safe nothrow @nogc;
void myfunc() pure safe nothrow nogc;

This will inevitably result in someone writing this:

pure safe nothrow nogc void myfunc();

which would still be invalid in this proposal, and I think this 
is still a problem but not a huge one since this is easily caught 
by the compiler.