accept @pure @nothrow @return attributes

[Zach the Mystic via Digitalmars-d]

On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:
>> 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

I think you meant someone else!

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

I don't think it is possible. Any non-keyword identifier is 
assumed to be the return type of the function. It all has to be 
solved in the parsing phase. You can't wait till semantic 
analysis to figure out what's a return type and what's an 
attribute. This is why D compiles so fast, because all phases of 
compilation are distinct.