accept @pure @nothrow @return attributes

Zach the Mystic via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 26 16:44:11 PST 2015


On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler 
wrote:
> Haha, ok, sorry for being too abstract.
>
> I think a safe way to implement my proposal would be to do what 
> c++ did and only allow non-keyword function attributes to omit 
> the '@' symbol if they appear after the function signature:
>
> 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)
>
> If the initial proposal is accepted by people, then we can talk 
> about the other examples, but let's focus on the proposal 
> before focusing on sub-proposals.

Alright, good. However... I'm still against it. Firstly, in my 
first comment in the current thread,

http://forum.dlang.org/post/uimpnhiweuitnnbeqshu@forum.dlang.org

...I made a list of considerations, among which:

3. Singularity of usage also matters. There should only be one
way to mark a given attribute, either with or without `@`.

This alone puts me at next to zero for your proposal in terms of 
benefit. It will strike people as a strange and unnecessary 
exception to the way to mark their attributes, for the sake of a 
slight beautification of only those cases where the attributes 
come after the signature. Consider me an old-fashioned "a keyword 
is a keyword is a keyword" kind of guy. Yes, there are outliers 
(C++, D, exit, success, etc.), but I don't see why that list 
should be expanded, as it is nicely contained, IMO.


More information about the Digitalmars-d mailing list