accept @pure @nothrow @return attributes

[Zach the Mystic via Digitalmars-d]

On Wednesday, 28 January 2015 at 18:37:48 UTC, Jonathan Marler 
wrote:
> On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei 
> Alexandrescu wrote:
>> On 1/28/15 10:19 AM, Jonathan Marler wrote:
>>> On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
>>>> On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan 
>>>> Marler wrote:
>>>>
>>>>> PLUS, this would be very simple to implement!
>>>>
>>>> Then I recommend you submit a pull request.
>>>>
>>>> Mike
>>>
>>> I would but Walter said no.  I'm certain he misunderstood my 
>>> proposal
>>> and I tried to explain it to him but I couldn't get him to 
>>> address it.
>>
>> Was that the proposal leading to this state of affairs 
>> (quoting from your post on 2015/01/26 16:05 PST?
>>
>>> Here's what would change
>>> -----------------------------------------------------------------
>>> void myfunc() nogc; // VALID (Only if this proposal is 
>>> accepted)
>>> void myfunc() safe; // VALID (Only if this proposal is 
>>> accepted)
>>>
>>>
>>> Here's what WOULD NOT change
>>> -----------------------------------------------------------------
>>> nogc myfunc(); // STILL INVALID: invalid unless it can be 
>>> verified
>>>              //          that this wouldn't result in 
>>> ambiguity
>>>              //          in the grammar
>>> void myfunc() @nogc; // STILL VALID (no change)
>>> @nogc myfunc(); // STILL VALID (no change)
>>
>>
>> Andrei
>
> You can follow this thread: 
> http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep@forum.dlang.org
>
> I explained my proposal 3 or 4 times but each time Walter 
> seemed to be misunderstanding my proposal saying it was going 
> to create "context-sensitive" tokens and so he would 
> immediately dismiss it.  I tried to understand what he meant by 
> "context-sensitive" tokens because my proposal didn't have 
> anything to do with them (at least my definition of them), but 
> even after he defined them my proposal clearly does not create 
> them.
>
> Walter "[A context-sensitive token is] A keyword in one context 
> and an identifier in another"
>
> Anyway, I'll restate my proposal again:
>
> 1. Modify the SYNTAX of function to allow it to be decorated 
> with IDENTIFIER tokens on the right hand side
>
> void foo() x; // valid SYNTAX (note: has not semantic meaning)
> void foo() safe; // valid SYNTAX and valid SEMANTICS
>
> 2. Modify the code that interprets the syntax tree to recognize 
> these identifiers as function attributes.
>
> A simple solution that would allow us to standardize where we 
> put the function attributes and allow us to remove the '@' 
> character from all non-keyword function attributes.  Seems like 
> a no-brainer to me.

I think a keyword is a keyword is a keyword. If it's a keyword to 
the right it should be one everywhere. How is somethign that's a 
built-in attribute one place and an identifier in another not 
context sensitive. Walter said that `exit`, `C++`, i.e. 
`scope(exit)`, `extern (C++)` etc. were never keywords, but I 
disagree. They are indeed context sensitive keywords. They have 
wisely been kept to a minimum. They are just confusing to reason 
about, except in the most strictly confined places, where they 
are now. I think that's why they're out of the question. They 
have wisely been kept to a minimum.