accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Tuesday, 27 January 2015 at 02:30:12 UTC, Zach the Mystic 
wrote:
> On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler 
> wrote:
>> 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.
>
> The third way is to do nothing, and live with the existing 
> inconsistency. It's not a bad choice, considering.
>
>> 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.
>
> I already suggested the best solution I could come up with: 
> break code in the most benign possible manner, using a 
> compiler-integrated 'dfix' experience. BTW, I'm glad you agree 
> with me about the ugliness of the @ sign. Even with dfix, the 
> decision could still be made to have everything use @'s, which 
> would be a solution to the consistency problem, but I would 
> only welcome it grudgingly. Good looking code is important to 
> me, and @ is *not* where that's @, so to say. :-)

Yes doing nothing is the other option :)  I'm kinda bummed we are 
in this situation in the first place.  If we had a consistent 
design in the first place it would have saved all this trouble.  
Now we can:

1. Live with it
2. Break code
3. Create inconsistency

I believe my proposal is how it should have been designed in the 
first place (allow identifiers to be function attributes), but 
not the only way to fix it is to choose 2 or 3.  I don't like 
either option but I feel like the community is more accepting of 
option 3 with a deprecation of the old methods.

The problem with doing nothing is these discussions are likely 
never going to end.  Someone will always bring up this issue and 
people are going to waste time forever debating what should be 
done.  Although I think it was you who suggested that we could 
simply document why it is the way it is, and that would help.  
Anyway, thanks for considering my proposal, I know you had to 
read a lot and you don't think it's a good idea but that's what 
these forums are for.