DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Fri, 20 Jun 2014 19:22:02 +0000
Brian Schott via Digitalmars-d <digitalmars-d at puremagic.com> 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.

I don't know. Why single out pure and nothrow? We also have public, final,
static, const, immutable, etc. all of which don't start with @. Only a very
few of the attributes start with @. So, it seems to me that changing pure and
nothrow to @pure and @nothrow is really just moving the inconsistency around
rather than fixing it. What's the point? The result is still inconsistent, and
it's still arbitrary as far as I can tell.

It's been suggested in this thread that this could help with attribute
negation, but the primary attribute that we've discussed as needing to be
negatable (final) is unaffected by this, so using @ as a way to lead to
introducing attribute negation doesn't really work. And some of the existing
@ attributes wouldn't make sense for negation (e.g. @safe), because they're
part of a group of three rather than two.

And as for attribute sets, I think that they're the kind of idea that _sounds_
like a good idea but is ultimately a bad idea. Yes, having a function marked
up like

auto foo() const @safe pure nothrow {...}

is annoyingly verbose, but it's _clear_, and by adding attribute sets, we'd be
opening the door to make it very unclear and confusing. If anyone can declare
their own attribute sets, then we could end up with as many new names for
attribute combinations as there are programmers using them. One person could
create @spn for @safe @pure @nothrow, whereas someone else creats
@safepurenothrow, etc.

And even if we created official attribute sets for the common stuff, you're
still creating a combinatorial explosion of attributes that people have to
know just so that they can put one attribute on a function instead of two to
four attributes.  I really don't think that that's a good tradeoff. I'd _much_
rather just leave things as they are. It may be verbose, but at least it's
clear.

I already think that it's bad enough that we have in on parameters being
aliased to two different storage classes - const and scope. And now we're
talking about not only adding _more_ items like that but making it so that
_anyone_ can define them. I think that it's a far better idea to just have
one way to mark something with a particular attributer rather than to find
ways to combine multiple attributes into a single attribute.

- Jonathan M Davis