accept @pure @nothrow @return attributes

[Jonathan Marler via Digitalmars-d]

On Tuesday, 27 January 2015 at 21:15:16 UTC, Daniel Kozak wrote:
> Jonathan M Davis via Digitalmars-d píše v Út 27. 01. 2015 v 
> 08:49 -0800:
>> On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via 
>> Digitalmars-d wrote:
>> > On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d 
>> > wrote:
>> > > You're right. I forgot about those two. But it's still the 
>> > > case that the
>> > > number of function attributes that don't have @ on them 
>> > > is_far_  greater
>> > > than the number of those that do.
>> >
>> > But I explained that most function attributes don't only 
>> > apply to
>> > functions but to variables as well:
>> >
>> > public, protected, package, private, static, const,
>> > immutable, inout, and deprecated
>> >
>> > So it can be consistent that the above don't use @.
>> >
>> > These only affect functions, not variables, so should be 
>> > @attributes IMO:
>> >
>> > final, override, abstract
>> >
>> > These affect both:
>> >
>> > return, ref
>> >
>> > So if we want some kind of consistency, we can achieve it by 
>> > adding @
>> > for final, override, abstract, and removing it for 'return'.
>> 
>> abstract also applies to classes, as does final. Also, if we 
>> end up adding
>> any new attributes later, they're bound to have @ on them to 
>> avoid requiring
>> a keyword (which is why we have @ on some of them in the first 
>> place), and
>> if the new attribute applies to variables or types as well, 
>> then the
>> division that you're suggesting falls apart.
>> 
>> IMHO, if we have to search for a way to make them consistent, 
>> then there's
>> no point. We're just going to end up with making things more 
>> consistent in
>> one way and less in another without necessarily making it any 
>> easier for
>> anyone to keep track of, so we'd just be shuffling things 
>> around. I think
>> that there needs to be a clear and solid benefit to changing 
>> which
>> attributes have @ and which don't, or we shouldn't mess with 
>> them.
>
> Exactly I do not think we can (want to) be 100% consistent . 
> Even If I
> really like to see every attribute to be with or without @ 
> (because
> consistency). I do not think it will be perfect. For eg. one of 
> things I
> like about D is how easy I can switch from PHP, Java C# or C++. 
> Even
> rewrite some of my code from PHP consist with following steps:
> 1.) remove $
> 2.) replace :: and -> for .
> 3.) some minor changes (sometimes nothing)
>
> So I would prefer if private, public, protected, final, static 
> stay
> without @,
> but D specific things like
> pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... 
> would go
> with @
>
> if I speak about immutable(const) I only mean function attribut 
> not
> storage. And It would be perfect if all theese must be on the 
> right
> side:
>
> // OK
> public final void someFunc() @immutable @safe @nogc @nothrow
> {
> }
>
> // OK
> public final immutable(int) someFunc() @immutable @safe @nogc 
> @nothrow
> {
>     return 5
> }
>
> // Deprecated
> public final immutable int someFunc() @immutable @safe @nogc 
> @nothrow
> {
>     return 5
> }
>
> // Error or Deprecated
> public final @immutable int someFunc() @safe @nogc @nothrow
> {
>     return 5
> }

Good idea.  The only think I would change is when an attribute 
appears on the right side, why not omit the '@' symbol :)  Other 
then that I like the consistency of putting the attributes in the 
same place.  But even if you kept the '@' symbol I would still 
prefer your proposal over what we have now.  It's more consistent 
and no longer looks weird.  When someone new comes along it makes 
sense and doesn't look like a hack.