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.
