On Thursday, 7 November 2013 at 07:29:16 UTC, Jacob Carlborg wrote:
> On 2013-11-07 07:48, Rob T wrote:
>
>> It's not zero benefit, although it may seem like that over a small
>> period of time, it's over an extended period that inconsistencies can
>> become a very significant cause of productivity loss. I'd rather fix up
>> my old code, and I know how horrible that is especially for production
>> code that is in use, it's just not fun, but if language stability was
>> more important to me than productivity, I would not have made the very
>> painful move from C/C++ to D.
>
> I agree with you. Unfortunately the those with commit access do not agree. They have no interest, what so ever, in breaking backward compatibility due to consistency.
>
> The result is exactly what happened with D1. At some arbitrary point in time it was decided that backwards compatibility must be kept, almost at all cost. This was decided even though the language and the standard library was far from stable.

If this is true, than D lost a chance to became more popular, unfortunately :'(

On Thursday, 7 November 2013 at 06:07:43 UTC, Benjamin Thaut wrote:
> Am 07.11.2013 05:45, schrieb Jonathan M Davis:
>> On Wednesday, November 06, 2013 22:11:02 Shammah Chancellor wrote:
>>> On 2013-11-07 02:04:36 +0000, Adam D. Ruppe said:
>>>> On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor wrote:

> What about gaining consitency? That was something D1 was really strong in, but D2 lost.

+1

+std.uni=>std.unicode

On Thursday, 7 November 2013 at 07:50:35 UTC, Daniel Kozak wrote:
> On Thursday, 7 November 2013 at 07:29:16 UTC, Jacob Carlborg wrote:
>> On 2013-11-07 07:48, Rob T wrote:

> If this is true, than D lost a chance to became more popular, unfortunately :'(

D1 or D2?

Anyway adding or removing @ will cause code breakage,
but leaving @ for UDAs it's better. It will be beautiful in words of consistency.

On 2013-11-07 08:39, Daniel Kozak wrote:

> What exactly do you mean?

You can do this:

@(1) void foo () { }
@(1) void bar () { }

Some library might treat @(1) in one way, and another library in a different way. If only user defined types were allowed the fully quailed name can be used do disambiguate the UDA's.

module libA;
struct attr { int a; }

module libB;
struct attr { int a; }

@libA.attr(1) void foo () { }
@libB.attr(1) void bar () { }

-- 
/Jacob Carlborg

On Thursday, 7 November 2013 at 08:09:09 UTC, eles wrote:
> On Thursday, 7 November 2013 at 07:50:35 UTC, Daniel Kozak wrote:
>> On Thursday, 7 November 2013 at 07:29:16 UTC, Jacob Carlborg wrote:
>>> On 2013-11-07 07:48, Rob T wrote:
>
>> If this is true, than D lost a chance to became more popular, unfortunately :'(
>
> D1 or D2?

D2

On Thursday, 7 November 2013 at 08:45:33 UTC, Jacob Carlborg
wrote:
> On 2013-11-07 08:39, Daniel Kozak wrote:
>
>> What exactly do you mean?
>
> You can do this:
>
> @(1) void foo () { }
> @(1) void bar () { }
>
> Some library might treat @(1) in one way, and another library in a different way. If only user defined types were allowed the fully quailed name can be used do disambiguate the UDA's.
>
> module libA;
> struct attr { int a; }
>
> module libB;
> struct attr { int a; }
>
> @libA.attr(1) void foo () { }
> @libB.attr(1) void bar () { }

I get it! Thanks :)

On Thursday, 7 November 2013 at 08:11:53 UTC, WasThere wrote:
> Anyway adding or removing @ will cause code breakage,
> but leaving @ for UDAs it's better. It will be beautiful in words of consistency.

Yes, but removing @ from @safe and others will mean more new keywords, so now I can have string system = "Linux" and bool safe = true.... But with adding @ to nothrow and others it will just break code use this keywords

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

> 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

I has thinking about it actually and come to same conclusion. You are right, be 100% consistent in this case would be worst than actual situation.