On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
> http://wiki.dlang.org/DIP64
>
> Attributes in D have two problems:
> 1. There are too many of them and declarations are getting too verbose
> 2. New attributes use @ and the old ones do not.
>
> I've created a DIP to address these issues.

Two years after, I think #1 would be a bad idea. I think it would overcomplicate most code for little benefit. Attributes aren't things that are easy to rally under a common name. Let's say that most people create their own set with "@safe @nogc @pure"... what should it be called? "@my_project_default"? Is there a name that would fit most projects so that many people can reuse it? Or will it have a different name for every project? In that case, not only would it complicate code reading, but what about mixing them? I foresee a *big* lot of issues with that for little benefit.

However I do think that the current state of attributes is too complicated too.

My take is that most people put the same attributes to almost every functions in a module because those functions are meant to work together. Therefore I think it would be more interesting to be able to set a new default for the module:

    @default = @safe @nogc @pure

    int foo(int i) { ... } // This function is @safe @nogc @pure
    int bar(int i) @pure { ... }  // This function is only @pure

I haven't of course gotten to the point where I'm able to write a DIP but I think it's worth a thought. Attributes look heavy when they're repeated. Setting a default value is the thing to do because it's what would be done with sets anyway, and it makes functions that do not follow the default rule look more imposant which is good: anything aside normality should be well-advertised.

About #2... come on, let's do it, consistency is a gift for the future. Of course code will break but it looks easy enough to fix.

On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:
> On Friday, 20 June 2014 at 19:22:04 UTC, Brian Schott wrote:
>> http://wiki.dlang.org/DIP64
>>
>> Attributes in D have two problems:
>> 1. There are too many of them and declarations are getting too verbose
>> 2. New attributes use @ and the old ones do not.
>>
>> I've created a DIP to address these issues.
>
> Two years after, I think #1 would be a bad idea.
>
> About #2... come on, let's do it, consistency is a gift for the future. Of course code will break but it looks easy enough to fix.

same, I neither do care about attribute sets but I'd like to see all function attributes will @. Even with an abnormaly long deprecation cycle if it's necessary, not to afraid those who wants to remain in their comfort zone.

On Monday, 18 April 2016 at 19:57:42 UTC, cym13 wrote:
>
>     @default = @safe @nogc @pure
>
>     int foo(int i) { ... } // This function is @safe @nogc @pure
>     int bar(int i) @pure { ... }  // This function is only @pure
>

Why not just put
@safe @nogc pure:
at the top? I feel like @default would really only help if you want to write
int foo(int i) @default { ... }

All things equal, I would probably prefer it as an alias
alias @default = @safe @nogc pure;

The biggest downside with this approach is that there's not enough attributes. For instance, you can't write
int bar(int i) @system @gc { ... }
While @system already exists, @gc doesn't. I believe this has also been discussed before on NG.

As an aside, the reason for not having function attribute inference everywhere is that it doesn't work when function bodies are not available. How common is this? I feel like I never write functions like this. Why not just make the rule that if the function body is available, then inference will happen?

Am Mon, 18 Apr 2016 20:49:45 +0000
schrieb jmh530 <john.michael.hall@gmail.com>:

> As an aside, the reason for not having function attribute inference everywhere is that it doesn't work when function bodies are not available. How common is this? I feel like I never write functions like this. Why not just make the rule that if the function body is available, then inference will happen?

Just because you don't know about it doesn't mean it's
non-existent. ;)
Imagine we had LibreOffice and Gtk+ or some other library with
many dependencies written in D. But even Phobos is a good
start. If all function bodies were available for attribute
inference that would start a cascade that requires the
compiler to perform semantic analysis on all of LibreOffice,
Gtk+ and whatever else is imported. It goes without further
explanation that this doesn't scale and .di files have to be
used at library boundaries.

-- 
Marco

On Monday, April 18, 2016 20:49:45 jmh530 via Digitalmars-d wrote:
> As an aside, the reason for not having function attribute inference everywhere is that it doesn't work when function bodies are not available. How common is this? I feel like I never write functions like this. Why not just make the rule that if the function body is available, then inference will happen?

There is no guarantee that the source code will be available, so the attributes cannot be infered in the general case. In addition, if you don't make the attributes explicit, you have the problem that you have no idea which attributes apply to a function, which makes managing them harder and on some level defeats the purpose of having them. Another major problem is that if the attributes aren't explicit, then it's far easier to accidentally break code by accidentally changing the attributes. We pretty much had to add attribute inference to the language to make attributes and templates work together (since which attributes will work is often dependent on the template arguments), but normal functions don't need that inference.

I would strongly argue that it's bad practice to rely on attribute inference when it's not required - even with templated functions. I'd even go so far as to argue that using labels like

@safe:

or blocks like

@safe
{
}

is generally bad practice, because it makes it harder to figure out which attributes apply to a given function, and while it might be nice to save on typing those extra characters for the attributes, you're causing more work for anyone who has to maintain those functions later - including yourself - because it's not immediately clear which attributes apply.

- Jonathan M Davis