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