accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Monday, 26 January 2015 at 22:04:48 UTC, Zach the Mystic wrote:
> 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.

Copy/Paste:

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

The return type doesn't appear after the function signature.