On Thursday, 7 November 2013 at 15:55:47 UTC, Jonathan M Davis wrote:
> 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?

One thing experimented with in Volt (D derivative) design is that all stuff that affects mangling/ABI gets own keyword without "@" and all stuff that fades away like UDA's is prefixed with "@". This implies @public and @private, yes, but is quite a simple and consistent rule on its own. We will see go it will work :) There are some tricky corner cases of course with stuff like @nogc/nogc.

P.S. There was a mention that introduction of UDA's has made addition of new @-prefixed built-ins impossible without breakage. It is not entirely true as symbols used in UDA's are qualified and conform to normal symbol lookup rules. Only problem is that built-in stuff is pure magic and has no own module.

On Thursday, 7 November 2013 at 16:24:38 UTC, Dicebot wrote:
> On Thursday, 7 November 2013 at 15:55:47 UTC, Jonathan M Davis wrote:
>> 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?
>
> One thing experimented with in Volt (D derivative) design is that all stuff that affects mangling/ABI gets own keyword without "@" and all stuff that fades away like UDA's is prefixed with "@". This implies @public and @private, yes, but is quite a simple and consistent rule on its own. We will see go it will work :) There are some tricky corner cases of course with stuff like @nogc/nogc.
>
> P.S. There was a mention that introduction of UDA's has made addition of new @-prefixed built-ins impossible without breakage. It is not entirely true as symbols used in UDA's are qualified and conform to normal symbol lookup rules. Only problem is that built-in stuff is pure magic and has no own module.

So, @ for UDA only?
+1

On Thursday, 7 November 2013 at 19:21:49 UTC, Michael wrote:
> So, @ for UDA only?
> +1

First, there is no point in "+1", it will never be in D as it is major breaking change :) Just some interesting experiment in similar but much younger language.

Second, no, it is not "@ for UDA only". It is "@ for everything that does not impact ABI, including all UDA and some built-in stuff like @public/@private/@package".

On Thursday, 7 November 2013 at 15:55:47 UTC, Jonathan M Davis wrote:
[..]
> 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
>
[...]

Very good points. It's a balancing act for sure.

The other inconsistencies are having multiple ways of doing the same things

Example

1) private { }
2) private:
3) private foo() { ... }

That's more to learn and more to document and different methods may confuse people new to D unless they are already preconditioned to it coming from a language like C++, however sometimes having these options are nice and do serve a useful purpose, although in the example 1 and 2 are redundant and 2 goes against the usual {} scope  concept, which is very unusual in terms of consistency.

The other thing I'd like to point out in terms of the hidden costs that inconsistencies create, is that these inconsistencies, and I refer to the ones that are not necessary and exist only for historical reasons and backwards compatibility, also have a negative effect on tool builders because there's more exceptions to the rule that the tools need to consider, and that will make tool building (to a degree) more difficult than necessary. One of the biggest weaknesses D has is a lack of tools, however D's inconsistencies are far less of an issue than some other languages with much better tool support, so it's not even close to a show stopper, it's just another irritation you have to put up with forever if historical inconsistencies are never resolved.

--rt

Am 07.11.2013 16:55, schrieb Jonathan M Davis:
> 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
>


Well if you ask me builtin attributes should not have the '@' so that only UDAs start with '@'.

I don't think that we are past the point of making breaking changes. the D user base it not that big. And those that are here are already used to stuff constantly breaking, otherwise they would be gone already. Also no one said they should be breaking right away. We can slowly deprecate them or at least provide both versions, so there is at least the option to make the D code consistent.


-- 
Kind Regards
Benjamin Thaut

On Thursday, November 07, 2013 21:00:08 Benjamin Thaut wrote:
> Am 07.11.2013 16:55, schrieb Jonathan M Davis:
> > 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
> 
> Well if you ask me builtin attributes should not have the '@' so that only UDAs start with '@'.
> 
> I don't think that we are past the point of making breaking changes. the D user base it not that big. And those that are here are already used to stuff constantly breaking, otherwise they would be gone already. Also no one said they should be breaking right away. We can slowly deprecate them or at least provide both versions, so there is at least the option to make the D code consistent.

With regards to the cost/benefit ratio, such a change fails miserably. This is exactly the sort of change that Walter and Andrei were talking about stopping completely at dconf, precisely because it doesn't actually fix anything. Breaking changes need to provide real, tangible benefits which are greater than the cost that they incur. And while I tend to agree that it would be better had none of the built-in attributes used @, changing it won't fix any bugs and won't make any software easier to mantain save perhaps for a tool which lexes/parses the language, and handling the few built-in attributes with @ is trivial in that case. The benefits are aesthetic, and changing it requires changing pretty much all existing D code. And even if you can avoid having the change break code immediately, it still requires changing the code, so it's not like that eliminates the cost of the change. It just spreads it out.

If you want anything like this to happen, you'll have to convince Walter and Andrei, and I would be shocked if they were ever convinced. They want to focus on stability, not on tweaking everything in search of making the language perfect. Breaking changes - especially breaking changes on this scale - need to provide real, tangible benefits which outweigh the cost of the breakage. And changing the @ attributes doesn't even come close.

- Jonathan M Davis

On 2013-11-07 17:24, Dicebot wrote:

> P.S. There was a mention that introduction of UDA's has made addition of
> new @-prefixed built-ins impossible without breakage. It is not entirely
> true as symbols used in UDA's are qualified and conform to normal symbol
> lookup rules. Only problem is that built-in stuff is pure magic and has
> no own module.

That only works if you always use fully qualified names for your UDA's:

enum foo;

@foo void bar () { }

Keyword "@foo" is introduced. Now you have a code breakage. Sure, it's an easy fix and you can keep the name of your UDA, but you still need to change every place where it's used.

Actually, I don't know what will happen if a keyword is introduce that has the same name as your top level package.

module top.level.pack;

enum foo;

module bar;

import top.level.pack;

@top.level.pack.foo void bar () { }

What happens if "@top" is introduced as a keyword?

-- 
/Jacob Carlborg

On Thursday, 7 November 2013 at 20:58:51 UTC, Jacob Carlborg wrote:
> What happens if "@top" is introduced as a keyword?

Pretty sure parser error will happen with current grammar.

I understand, but by subject main line it's very discouraging and adds some confusion for new D users. In this case +1 of me.

I consider it like investment with profit in future and nothing at start.

I don't have now a dev env, but what with @safe(9000)... ?

Am 07.11.2013 21:16, schrieb Jonathan M Davis:
>
>
> If you want anything like this to happen, you'll have to convince Walter and
> Andrei, and I would be shocked if they were ever convinced. They want to focus
> on stability, not on tweaking everything in search of making the language
> perfect. Breaking changes - especially breaking changes on this scale - need
> to provide real, tangible benefits which outweigh the cost of the breakage. And
> changing the @ attributes doesn't even come close.
>
> - Jonathan M Davis
>

I never said that I think this is actually going to happen. I just said it would be a good idea because it would help with consistency.

Kind Regards
Benjamin Thaut