accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic 
wrote:
> On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler 
> wrote:
>> On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
>>> 3. Singularity of usage also matters. There should only be one
>>> way to mark a given attribute, either with or without `@`.
>>
>> 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?
>
> The consistency issue is precisely that there should not be 
> more than one way to write an attribute. Note that that's 
> precisely where most of the opposition to this thread's 
> original proposal came from. Uniformity means never having to 
> explain to anybody why there is more than one way to do 
> something. Both this thread's proposal and your proposal 
> *introduce* inconsistency in this way.
>
>> 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.
>
> This will annoy people even more than they are already annoyed 
> by the `@`-on-some-attributes-and-not-others inconsistency. The 
> latter type (type 2 in my first thread) already exists in the 
> language, but it shoudln't be replaced by another type. This 
> argument was already made by Jonathan Davis.

Yes you're right it adds more inconsistency (sorry what I said 
was wrong).  However, no matter what solution you choose you have 
to choose one of two evils.  Either add inconsistency or break 
code.  There's no way around it.  If you ADD another way to write 
the attributes that looks better, you've created more 
"inconsistency".  If you REPLACE the existing way to write 
attributes, you've now broken code.

I proposed that we ADD another way of writing attributes, 
however, my proposal doesn't require that we ADD another way, 
instead, we can REPLACE the current way of writing attributes by 
normalizing where they appear.  However, like I said, you have to 
choose one or the other, broken code or inconsistency.

The nice part about ADDING another way of writing attributes is 
that the hope is that the inconsistency will be solved in the 
future.  Changing the way to write attributes will introduce more 
inconsistency at first.  However, the hope is that if the new way 
is "better" or looks "nicer", then developers will hopefully 
consistently choose the new way. Then, if there's no reason to 
keep the old way, it can be deprecated and the consistency issue 
is solved.

So again, I was suggesting one way of implementing my proposal 
which was to add an inconsistency, but you could implement it 
another way but you would have to break code.  Do you have a 
solution that doesn't do either?  I think if you try to find one, 
you'll see that I'm right in saying you're going to have to 
choose one or the other.