Why the @ in @safe? & UDAs

Jonathan M Davis jmdavisProg at gmx.com
Thu Nov 7 07:55:31 PST 2013


On Thursday, November 07, 2013 07:07:44 Benjamin Thaut wrote:
> What about gaining consitency? That was something D1 was really strong
> in, but D2 lost.

Then should public and private be @public and @private in order to be 
consistent? Then we'd be inconsistent with C++, Java, C# etc. which would make 
it that much harder for folks to learn D. Would you want @static and @const?

I don't think that you can be 100% consistent. If nothing else, as soon as you 
make one thing consistent, it often ends up being inconsistent with something 
else. And sometimes consistency costs us. For instance, this is perfectly 
legal

const Object foo();

and is equivalent to

Object foo() const;

because that's the way it is for every other attribute, but it's a source of 
confusion and bugs, because most everyone seems to expect that

const Object foo();

would be equivalent to

const(Object) foo();

I understand why it would be desirable to try and make all of the attributes 
consistent, and if we were starting from scratch or were fairly early along in 
language development, then I'd be in favor of it. But we're way too far along 
at this point IMHO. The only practical benefit to making such changes now would 
be to try and make the language easier for newcomers - which is a laudible 
goal to be sure, but I don't think that the cost of having to know that it's 
@safe, @trusted, and @system whereas ever other language-defined attribute 
lacks @ is particularly high - particularly when the cost of fixing it is 
breaking pretty much every D program in existence. It's just a small quirk 
that you have to learn, and then it's not really a problem anymore.

The benefits of such a change would be almost purely aesthetic, and it would 
break _everyone_'s code without adding any practical benefit whatsoever.

I'm probably the person who's broken the most code due to making changes to 
Phobos in order to make its symbol names consistent, so I'm definitely in favor 
of making the language and its libraries consistent and see value in that, but 
I think that we're past the point where we can afford such breaking changes 
(and this suggested change would break far more than any change to Phobos ever 
has). We need to be stable, or no one is going to use D. And breaking every D 
program in existence over an aesthetic issue is just going to harm our 
reputation in that regard. We finally seem to be starting to shake off the 
reputation for breaking code that we've had, and our stability continues to 
increase. We don't want to turn around and make such a large breaking change 
for aesthetic reasons. That would not only tick off the majority of our 
existing user base, but it would scare away many of the newbies that this 
change would be supposed to help.

- Jonathan M Davis


More information about the Digitalmars-d mailing list