accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Tuesday, 27 January 2015 at 01:55:30 UTC, Walter Bright wrote:
> On 1/26/2015 3:07 PM, Jonathan Marler wrote:
>> Walter I hate to waste your time in answering my silly 
>> questions.  I know you
>> have a much deeper knowledge and understanding of the language 
>> then I.  I can
>> see that you believe my suggestion would create some 
>> unnecessary complexity
>> ("It's like using a nail for a cotter pin"), however, I can't 
>> see how it would
>> so I'm going to ask another question. I can see that you are 
>> trying to save time
>> from your short responses so I'll understand if I understand 
>> if you feel I'm a
>> lost cause and do not respond again.
>>
>> You said you strongly dislike "context-sensitive" tokens but I 
>> still don't know
>> exactly what you mean by "context-sensitive". You said a token 
>> is
>> "context-sensitive" if it is "A keyword in one context and an 
>> identifier in
>> another".  However, since I'm not proposing that "save" and 
>> "nogc" be keywords
>> in any context, this doesn't appear to fall under your 
>> definition.  So I must
>> assume your real definition is more general. However, if the 
>> definition is too
>> general then couldn't you consider almost any token 
>> "context-sensitive".  For
>> example, the token "static" or "ref" have different meanings 
>> depending on their
>> context, so are they "context-sensitive"?  Yes they are still 
>> keyword tokens,
>> but "safe" and "nogc" would still just be regular id tokens so 
>> what makes "safe"
>> and "nogc" more "context-sensitive" then "static" and "ref"?
>>
>> I'm honestly trying to understand.  I can see from how the 
>> grammar works that
>> you don't agree my solution is a good one, but I'm failing to 
>> understand why.  I
>> fail to see how allowing a function to be decorated with id 
>> tokens is more
>> complex then only allowing keywords.  Also sorry for harping 
>> on definitions,  I
>> majored in Computer Science and Mathematics...having strict 
>> definitions comes
>> from my days of writing endless proofs.
>
> Your argument boils down to there are no such things as token 
> keywords. Yes, you can make a language work like that. I've 
> seen it done. It is awful. The solution is clear:
>
>    static is a keyword. You can NEVER use it as an identifier. 
> Same with all other keywords.

This has become quite frustrating.  I'm not sure how else to 
explain myself so maybe I'm just being dumb. Something inside me 
wants to explain myself again so I'll try one more time, if this 
fails, then it must be me not understanding your explanation and 
I'll give up. My proposal has nothing to do with keywords, it can 
be summarized with the following 2 steps:

1. Change the syntax of a function to allow it to be decorated 
with general id tokens.

2. Modify code generation to look at these new tokens and treat 
them as function attributes.

I would suggest only allowing these id tokens to appear after the 
function arguments so as not to introduces any ambiguity in the 
grammar.

void myfunc() pure safe nothrow nogc;

  pure (still a keyword, no change)
  safe (still NOT a keyword, no change)
  nothrow (stil a keyword, no change)
  nogc (still NOT a keyword, no change)

My proposal is not trying making tokens "context-sensitive" by 
treating them as keywords sometimes and identifiers at other 
times.  All it is doing is allowing an identifer token to be used 
as a function attribute.  Nothing to do with keywords.