DIP64: Attribute Cleanup

[Jonathan M Davis via Digitalmars-d]

On Sat, 21 Jun 2014 17:54:33 +0000
Peter Alexander via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Saturday, 21 June 2014 at 17:20:08 UTC, Brian Rogoff wrote:
> > I completely agree with your point, but if things never get
> > cleaned up we'll need a guy like Scott Meyers to explain the
> > overcomplicated result. I don't know how to resolve this issue,
> > opponents of change will claim that a language will never get
> > traction if it changes too much too quickly, and proponents
> > will claim that not removing inconsistencies leads to a mess.
> > Both are right.
>
> Like most things in engineering, there is no right answer, and
> there are compromises all the way. You just have to weigh up the
> pros and cons and make a decision. Of course, reasonable people
> may disagree on the weights, so some debate may be necessary.
>
> The pros and cons are clear here. I think it would be nice to
> have consistent syntax and keep Scott away, but it's just syntax.
> It doesn't affect the expressiveness, power, or performance of
> the language. The cost is that it breaks almost all working code.
> I do not think the pros outweigh the cons, so I do not think this
> should go ahead, and we will just have to live with Scott
> explaining why some attributes have @ and others do not.

And to add to that, this proposal doesn't even make things consistent. You
_still_ have to explain why some attributes have @ and some don't. It's just
that now two of them have @ whereas they didn't before. final, static, public,
const, etc. all still don't have @, and they're all function attributes too.
So, it doesn't increase consistency. It just moves it around. And then we have
to explain why some older code or tutorials _don't_ have @ on pure or nothrow,
making it so that we have _more_ to explain.

I appreciate the sentiment of wanting to clean things up and make them more
consistent, but I really don't think this does that. If we want that, we'd
either have to add @ to all attributes or remove it from all attributes. But
then of course, we'd have stuff like @public and @static, which is
inconsistent with other languages and would probably cause folks to complain
about unnecessary inconsistencies with othe languages. So, I really don't
think that we can avoid this problem. It's just a question of which form of it
we want to deal with and how much code breakage we're willing to put up with
to get it there.

- Jonathan M Davis