accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler 
> wrote:
>> I agree with Jonathan's points, this solution doesn't seem 
>> like an improvement.   If I understand the problem, we don't 
>> want to make every attribute use the '@' symbol because it 
>> looks bad and would cause a lot of code changes for sake of 
>> consistency.  However, on the other hand, we don't want to 
>> support the new properties because we have to add them as 
>> keywords which would break code using those words and would 
>> make the language more restrictive (nothing can be named 
>> nogc/safe/...).
>>
>> Assuming I understand the problem, couldn't we modify the 
>> language grammar to support more attributes without making 
>> them keywords?  Then we can omit the '@' on future code (and 
>> fix the old code if we want) and we don't have to litter the 
>> language with new keywords.
>>
>> I understand that doing this may be fairly complicated.  This 
>> may create some ambiguities in the grammar that would need to 
>> be handled carefully, but if it can work I think this would be 
>> a good option.
>
> I think the short answer is that it's WAY too complicated for 
> the benefit. Also, why burden the syntax highlighter, let alone 
> the human reader, with ambiguities like this?

I wasn't saying that we should introduce ambiguity, I was saying 
we should be careful not to introduce ambiguity.  I wrote that to 
indicate that I wasn't sure if the solution would introduce 
ambiguity or not.  Zach suggested a solution that I'm fairly 
certain would be unambiguous (it's nice to have c++ people who've 
already seen the same problem know of a solution).  By 
restricting the attributes to only appear after a function 
signature, it would also normalize the issue of consistent 
location of attributes, but this is another debate.  However, 
allowing the attributes to appear before the function signature 
*might* work, but that would require much more care and may not 
even be possible (like I said, I'm not sure).  A comprimize could 
be to allow attributes to omit the '@' character if they appear 
after the function signature and require the '@' character if 
they appear before.  I'm not saying that's a good idea, just an 
option.