www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why the in safe? & UDAs

reply Shammah Chancellor <S S.com> writes:
My understanding is that   attributes were for used-defined behavior 
only.   Pure and nothrow, since the compiler implements behavior on 
those keywords, do not have the   sign.   So, why is  safe,  safe, and 
not just "safe".

On the basis that  attributes should not have compiler defined 
behavior.   Please take off the   from the  safe.   This would apply to 
 trusted as well.

Also,  I think that having UDAs (user defined attributes) be freeform, 
and not a class following some interface is asking for trouble.  It 
makes them hard to use reflection with, and it also causes the 
potential for modules to use the same literal for different purposes.  
I think C# has this right.
Nov 06 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor 
wrote:
 My understanding is that   attributes were for used-defined 
 behavior only.
It is all a historical thing... at first, all new things were done as keywords. Then around the time safe came around, they were changing their minds and new things became keywords. Then, some time after that, UDAs came around and used the syntax. But the reason it is pure and safe instead of pure safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.
Nov 06 2013
next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 7 November 2013 at 02:04:37 UTC, Adam D. Ruppe wrote:
 On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah 
 Chancellor wrote:
 My understanding is that   attributes were for used-defined 
 behavior only.
It is all a historical thing... at first, all new things were done as keywords. Then around the time safe came around, they were changing their minds and new things became keywords. Then, some time after that, UDAs came around and used the syntax.
More specifically, the discussion was around properties and how to handle them. User-Defined attributes were also being thrown around, and at some point a suggestion combined the two suggesting properties be denoted with property. Some time passed and suddenly D could parse property on functions ( safe may have been added at the same time, or a little later). No UDA[1] was introduced. 1. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Nov 06 2013
prev sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
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:
 My understanding is that   attributes were for used-defined behavior only.
It is all a historical thing... at first, all new things were done as keywords. Then around the time safe came around, they were changing their minds and new things became keywords. Then, some time after that, UDAs came around and used the syntax. But the reason it is pure and safe instead of pure safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.
There's an easy solution to that. Put warnings on pure, nothrow, and immutable ( in the function tag context) and add pure, nothrow, immutable etc. Fix it going forward and eventually remove it.
Nov 06 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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:
 My understanding is that   attributes were for used-defined behavior
 only.
It is all a historical thing... at first, all new things were done as keywords. Then around the time safe came around, they were changing their minds and new things became keywords. Then, some time after that, UDAs came around and used the syntax. But the reason it is pure and safe instead of pure safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.
There's an easy solution to that. Put warnings on pure, nothrow, and immutable ( in the function tag context) and add pure, nothrow, immutable etc. Fix it going forward and eventually remove it.
And gain what? You force everyone to change their code for essentially zero benefit. - Jonathan M Davis
Nov 06 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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:
 My understanding is that   attributes were for used-defined behavior
 only.
It is all a historical thing... at first, all new things were done as keywords. Then around the time safe came around, they were changing their minds and new things became keywords. Then, some time after that, UDAs came around and used the syntax. But the reason it is pure and safe instead of pure safe or pure and safe is just historical accident - they were introduced in that particular phase, and now the worry is changing it will annoyingly break too much code for very little real benefit.
There's an easy solution to that. Put warnings on pure, nothrow, and immutable ( in the function tag context) and add pure, nothrow, immutable etc. Fix it going forward and eventually remove it.
And gain what? You force everyone to change their code for essentially zero benefit. - Jonathan M Davis
What about gaining consitency? That was something D1 was really strong in, but D2 lost.
Nov 06 2013
next sibling parent "eles" <eles eles.com> writes:
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
Nov 07 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Nov 07 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Nov 07 2013
next sibling parent reply "Michael" <pr m1xa.com> writes:
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
Nov 07 2013
parent reply "Dicebot" <public dicebot.lv> writes:
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".
Nov 07 2013
parent "Michael" <pr m1xa.com> writes:
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)... ?
Nov 07 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 07 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Nov 07 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 7 November 2013 at 20:58:51 UTC, Jacob Carlborg 
wrote:
 That only works if you always use fully qualified names for 
 your UDA's:
 ...
Btw, what I have meant originally is that if built-in attributes where provided by some runtime module similar to object.d (instead of being part of grammar), one could use specialized imports at module top-level to prioritize them over built-in ones and make transition trivial: ``` import myudamodule : property; // ... property // explicit symbol import has higher priority over normal one, no name clash void foo() {} ```
Nov 07 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-07 23:23, Dicebot wrote:

 Btw, what I have meant originally is that if built-in attributes where
 provided by some runtime module similar to object.d (instead of being
 part of grammar), one could use specialized imports at module top-level
 to prioritize them over built-in ones and make transition trivial:
 ```
 import myudamodule : property;

 // ...

  property // explicit symbol import has higher priority over normal one,
 no name clash
 void foo() {}
 ```
Oh, you mean like that. I guess that could work. -- /Jacob Carlborg
Nov 07 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
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
Nov 07 2013
parent "QAston" <qaston gmail.com> writes:
On Thursday, 7 November 2013 at 19:59:28 UTC, Rob T 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?

 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. --rt
I like that I don't have to repeat private with every declaration.
Nov 08 2013
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Nov 07 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Nov 07 2013
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
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
Nov 07 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 7 November 2013 at 20:16:46 UTC, Jonathan M Davis 
wrote:
 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.
I tend to lean towards this position with time more and more. Problem is, stuff that bothers me most in D which I'd like to change in a breaking way is not lack of some new features or re-engineering of some specific syntax. Under-explored semantics of some core language parts are most frustrating in my every-day development - like tuples or attribute defaults or symbol visibility. But changing/fixing those will yield completely different language, something like D3, it is not some incremental augmentation. And when it comes to exiting feature set - D2 is already so much ahead of C++ that I tend to desire more stability / "industrial quality" to act as replacement right here and now. No single improvement will benefit as much as simple proof that D community can craft tool set that "just works". In that sense, any proposed addition must be either completely in style with existing language state or give really enormous benefits. Being simply good is not enough. Of course, good stuff is still worth discussing - language design moves forward and D3 is inevitable, whatever Walter intention here is. There are already D derivatives that do experiment in that domain trying to build on D experience foundation in the very same way as D did on top of C/C++. But that is completely different story - D upstream itself must first prove itself capable of producing at least single mature language version / implementation before moving forward.
Nov 07 2013
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 7 November 2013 at 22:16:43 UTC, Dicebot wrote:
 Of course, good stuff is still worth discussing - language 
 design moves forward and D3 is inevitable, whatever Walter 
 intention here is. There are already D derivatives that do 
 experiment in that domain trying to build on D experience 
 foundation in the very same way as D did on top of C/C++.
This raises a question for me: should we perhaps take a page from X.org [0] and document all the niggling finer points of what the "next D" should be or not be? It's not gospel (and in the case of X12, may never actually happen), but it's still a useful reflection point and consolidation of the various disparate "should have done" things. Like pure/safe/immutable holes, virtual/final, what the various forks [1] and experiments [2] are and why they exist, etc. These points come up in conversations, but as we eschew breaking changes with ever-greater fervour, we should still make note of them. They don't need to be DIPs (though some of the ones in limbo would be valuable additions [3]), or even extensively described. If nothing else, it'd be a list of issues we're aware of that could be "better" (like the one in the parent thread) to direct people toward. A succinct history "why this one part sucks". -Wyatt [0] http://www.x.org/wiki/Development/X12/ [1] https://github.com/FeepingCreature/fcc [2] https://github.com/VoltLang [3] http://wiki.dlang.org/DIP23 No, I won't ever give up. This is important. :<
Nov 08 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/08/2013 02:31 PM, Wyatt wrote:
 [3] http://wiki.dlang.org/DIP23 No, I won't ever give up. This is
 important. :<
Please do. Excerpts: struct S { property Type foo(); // formal getter property void bar(Type); // formal setter property ref Type baz(); // ref return getter == auxiliary setter } // Taking the address reveals the delegate static assert(is(typeof(&s.foo) == ref Type delegate())); // Changing precedence with parens reveals the returned type static assert(is(typeof(&(s.foo)) == Type*)); // --- struct S { Type foo(); // 0-arg function void bar(Type n); // 1-arg function ref Type baz(); // 0-arg ref return function } // Getting address of delegate static assert(is(typeof(&s.baz) == ref Type delegate())); // Getting address of return static assert(is(typeof(&(s.baz)) == Type*)); It completely beats me how anyone can consider this a good idea. Seriously, this is broken. Furthermore, the DIP is too informal and fails to handle all relevant cases. I'd rather get rid of property completely than to approve of DIP23. See http://wiki.dlang.org/DIP24 (TLDR: The full proposal makes properties behave like ordinary variables except that their address cannot be taken and there could be more postblit/destructor invocations in a given expression. There is a __traits to get the underlying getter/setter function symbols for properties.)
Nov 08 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
"Thread hijacking" achievement unlocked ;)

On topic of such wiki page - it is kind of nice to have but lot 
of potential entries are controversial and need some serious 
discussion (for example, I'd place optional parens there as 
damaging mistake but reasonable people will disagree :P) before 
being documented. It risks being biased to preferences of view 
editors or turn into edit wards :) I don't know what is a good 
way to do this without devoting too much efforts.
Nov 08 2013
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote:
 "Thread hijacking" achievement unlocked ;)
Now, now, I changed the title. If this were a proper hijack, I'd be trying to extract a ransom (like fixed AAs). ;)
 On topic of such wiki page - it is kind of nice to have but lot 
 of potential entries are controversial and need some serious 
 discussion (for example, I'd place optional parens there as 
 damaging mistake but reasonable people will disagree :P) before 
 being documented. It risks being biased to preferences of view 
 editors or turn into edit wards :) I don't know what is a good 
 way to do this without devoting too much efforts.
I don't think it needs to be that strict. Optional parentheses are something that there are mixed opinions on, so that should be noted. It may be better to think of it as "things to reconsider in the next version"-- discuss later, once we have a lot more time with the current stuff and it's actually TIME to hash out the future. "Not gospel" means it's okay for things like that to be in there. Heck, compare the vision for X12 with what Wayland [0] is actually shaping up to be: they're...rather different. ;) (I'm aware that being "the next X11" wasn't Kristian's goal and it was originally an experiment to be folded into X.org, but reality is weird.) -Wyatt [0] http://wayland.freedesktop.org/architecture.html
Nov 08 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
I'd love to have a centralized page/wiki/site that would contain:

* D design flaws
* proposed improvements (including far ranging ones)

otherwise it gets lost in emails


On Fri, Nov 8, 2013 at 6:49 AM, Wyatt <wyatt.epp gmail.com> wrote:

 On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote:

 "Thread hijacking" achievement unlocked ;)

  Now, now, I changed the title.  If this were a proper hijack, I'd be
trying to extract a ransom (like fixed AAs). ;) On topic of such wiki page - it is kind of nice to have but lot of
 potential entries are controversial and need some serious discussion (for
 example, I'd place optional parens there as damaging mistake but reasonable
 people will disagree :P) before being documented. It risks being biased to
 preferences of view editors or turn into edit wards :) I don't know what is
 a good way to do this without devoting too much efforts.
I don't think it needs to be that strict. Optional parentheses are something that there are mixed opinions on, so that should be noted. It may be better to think of it as "things to reconsider in the next version"-- discuss later, once we have a lot more time with the current stuff and it's actually TIME to hash out the future. "Not gospel" means it's okay for things like that to be in there. Heck, compare the vision for X12 with what Wayland [0] is actually shaping up to be: they're...rather different. ;) (I'm aware that being "the next X11" wasn't Kristian's goal and it was originally an experiment to be folded into X.org, but reality is weird.) -Wyatt [0] http://wayland.freedesktop.org/architecture.html
Nov 08 2013
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 9 November 2013 at 00:12:22 UTC, Timothee Cour wrote:
 I'd love to have a centralized page/wiki/site that would 
 contain:

 * D design flaws
 * proposed improvements (including far ranging ones)

 otherwise it gets lost in emails
Just need a single person to start the wiki page and define default entry formatting ;)
Nov 09 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 8 November 2013 at 14:21:45 UTC, Dicebot wrote:
 "Thread hijacking" achievement unlocked ;)

 On topic of such wiki page - it is kind of nice to have but lot 
 of potential entries are controversial and need some serious 
 discussion (for example, I'd place optional parens there as 
 damaging mistake but reasonable people will disagree :P) before 
 being documented. It risks being biased to preferences of view 
 editors or turn into edit wards :) I don't know what is a good 
 way to do this without devoting too much efforts.
You could allow comments at the bottom of the page, or like wikipedia, add a comments page to the DIP ?
Nov 09 2013
prev sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 8 November 2013 at 14:12:04 UTC, Timon Gehr wrote:
 See http://wiki.dlang.org/DIP24 (TLDR: The full proposal makes 
  properties behave like ordinary variables except that their 
 address cannot be taken and there could be more 
 postblit/destructor invocations in a given expression. There is 
 a __traits to get the underlying getter/setter function symbols 
 for properties.)
Oh, right, that one. Whoops. DIP23 was just the flashpoint for the most recent braw^w discussion. There were like four, but I just grabbed the link for the one that "looked sorta right" without rereading. My bad. :V The point is properties are a furball and need to be fixed, so I'll keep making noise about it from time to time. -Wyatt
Nov 08 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Thursday, 7 November 2013 at 20:16:46 UTC, Jonathan M Davis 
wrote:
 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
I would add that constant breaking changes make the language unfit for industrial usage in the long term. Let's remember that D is being pushed in production by Andrei at Facebook. If the language breaks everything at each release, there is no way Facebook or any other company for that matter is going to bet a dime on it.
Nov 09 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/9/13 1:27 AM, SomeDude wrote:
 I would add that constant breaking changes make the language unfit for
 industrial usage in the long term.
 Let's remember that D is being pushed in production by Andrei at
 Facebook. If the language breaks everything at each release, there is no
 way Facebook or any other company for that matter is going to bet a dime
 on it.
Agreed with qualifications. We at Facebook are well aware that bumping the gcc release will inevitably cause breakages, and are able and willing to put up with them for the sake of the benefits. This of course is guided by the breakage/benefits ratio. Andrei
Nov 10 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
 On 11/9/13 1:27 AM, SomeDude wrote:
 I would add that constant breaking changes make the language unfit for
 industrial usage in the long term.
 Let's remember that D is being pushed in production by Andrei at
 Facebook. If the language breaks everything at each release, there is no
 way Facebook or any other company for that matter is going to bet a dime
 on it.
Agreed with qualifications. We at Facebook are well aware that bumping the gcc release will inevitably cause breakages, and are able and willing to put up with them for the sake of the benefits. This of course is guided by the breakage/benefits ratio. Andrei
What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?
Nov 10 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/10/13 11:14 AM, Timon Gehr wrote:
 On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
 On 11/9/13 1:27 AM, SomeDude wrote:
 I would add that constant breaking changes make the language unfit for
 industrial usage in the long term.
 Let's remember that D is being pushed in production by Andrei at
 Facebook. If the language breaks everything at each release, there is no
 way Facebook or any other company for that matter is going to bet a dime
 on it.
Agreed with qualifications. We at Facebook are well aware that bumping the gcc release will inevitably cause breakages, and are able and willing to put up with them for the sake of the benefits. This of course is guided by the breakage/benefits ratio. Andrei
What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?
That's nice because in a good way it puts the onus on the breakers. For it to be useful, the tool would have to be rock solid and work in 100% cases. Andrei
Nov 10 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 10 November 2013 at 19:24:53 UTC, Andrei Alexandrescu 
wrote:
 On 11/10/13 11:14 AM, Timon Gehr wrote:
 On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
 On 11/9/13 1:27 AM, SomeDude wrote:
 I would add that constant breaking changes make the language 
 unfit for
 industrial usage in the long term.
 Let's remember that D is being pushed in production by 
 Andrei at
 Facebook. If the language breaks everything at each release, 
 there is no
 way Facebook or any other company for that matter is going 
 to bet a dime
 on it.
Agreed with qualifications. We at Facebook are well aware that bumping the gcc release will inevitably cause breakages, and are able and willing to put up with them for the sake of the benefits. This of course is guided by the breakage/benefits ratio. Andrei
What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?
That's nice because in a good way it puts the onus on the breakers. For it to be useful, the tool would have to be rock solid and work in 100% cases. Andrei
string mixins?
Nov 10 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/10/2013 08:45 PM, John Colvin wrote:
 On Sunday, 10 November 2013 at 19:24:53 UTC, Andrei Alexandrescu wrote:
 On 11/10/13 11:14 AM, Timon Gehr wrote:
 On 11/10/2013 05:39 PM, Andrei Alexandrescu wrote:
 On 11/9/13 1:27 AM, SomeDude wrote:
 I would add that constant breaking changes make the language unfit for
 industrial usage in the long term.
 Let's remember that D is being pushed in production by Andrei at
 Facebook. If the language breaks everything at each release, there
 is no
 way Facebook or any other company for that matter is going to bet a
 dime
 on it.
Agreed with qualifications. We at Facebook are well aware that bumping the gcc release will inevitably cause breakages, and are able and willing to put up with them for the sake of the benefits. This of course is guided by the breakage/benefits ratio. Andrei
What about just shipping a fully automated fix-up tool when trivial but major breaking changes happen?
That's nice because in a good way it puts the onus on the breakers. For it to be useful, the tool would have to be rock solid and work in 100% cases. Andrei
string mixins?
Just let CTFE thread through additional state describing the locations of the constant literals the code is assembled from, and make sure the fix-ups do not influence anything else. For the off chance that some part of the generated code that we want to change is actually computed from other data, it is still possible to require manual interaction, but I don't know of any real code for which this might be the case. Code relying on stringof, eg. stringof returning ' safe' in types instead of 'safe' would be quite hard to handle as well, but it should still be possible to handle the relevant subset of cases. Of course, such a tool would be quite a piece of engineering. :o)
Nov 10 2013
parent "Kapps" <opantm2+spam gmail.com> writes:
On Sunday, 10 November 2013 at 20:12:39 UTC, Timon Gehr wrote:
 Code relying on stringof, eg. stringof returning ' safe' in 
 types instead of 'safe' would be quite hard to handle as well, 
 but it should still be possible to handle the relevant subset 
 of cases.
I think it was somewhat decided that .stringof can't be relied upon anyways, when it changed and broke a bit of existing code previously.
Nov 10 2013
prev sibling next sibling parent reply "Michael" <pr m1xa.com> writes:
 What about just shipping a fully automated fix-up tool when 
 trivial but major breaking changes happen?
search/replace regexp ?)
Nov 10 2013
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 10 November 2013 at 19:30:30 UTC, Michael wrote:
 search/replace regexp ?)
I think the way I'd do it is combine that with the compiler. So you compile your code. The compiler generates an error. The fixup script checks the errors against the pattern it has and then does the necessary changes on the file, then writes it back out (perhaps doing a backup and/or user confirmation, like replacing files on a copy: yes, no, yes to all, with yes to all just following that same pattern - if it is a different class of error message, or if the replace would replace two things when it should only be one, it asks for confirmation again) This actually shouldn't be too hard to write for quite a few things, and using actual errors would be more reliable than a plain find/replace. The interactive session can go pretty fast $ fixup error foo.d line 30 undefined identifier safe safe void foo() { replace with safe void foo() { # BTW I'd highlight the replacement in color too y/n/yes to all/no to all? yes to all boom
Nov 10 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
This is exactly what I suggested at Dconf, and this is what go has done
with go fix:
http://golang.org/cmd/fix/
so it can definitely be done. After using that, user can just use git diff
and see summary of changes if he wants. That is *the* path to improving D's
API. Code with source can be changed, compiled code without source doesn't
need to be changed.
The discussion should focus on how to help with harder cases involving
string mixins found while executing CTFE.
Btw, refactoring code with AST macros should be easier than with string
mixins.


On Sun, Nov 10, 2013 at 11:36 AM, Adam D. Ruppe
<destructionator gmail.com>wrote:

 On Sunday, 10 November 2013 at 19:30:30 UTC, Michael wrote:

 search/replace regexp ?)
I think the way I'd do it is combine that with the compiler. So you compile your code. The compiler generates an error. The fixup script checks the errors against the pattern it has and then does the necessary changes on the file, then writes it back out (perhaps doing a backup and/or user confirmation, like replacing files on a copy: yes, no, yes to all, with yes to all just following that same pattern - if it is a different class of error message, or if the replace would replace two things when it should only be one, it asks for confirmation again) This actually shouldn't be too hard to write for quite a few things, and using actual errors would be more reliable than a plain find/replace. The interactive session can go pretty fast $ fixup error foo.d line 30 undefined identifier safe safe void foo() { replace with safe void foo() { # BTW I'd highlight the replacement in color too y/n/yes to all/no to all? yes to all boom
Nov 10 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-10 20:14, Timon Gehr wrote:

 What about just shipping a fully automated fix-up tool when trivial but
 major breaking changes happen?
Yet again, where's that D front end as a library when we need it. -- /Jacob Carlborg
Nov 10 2013
prev sibling parent reply "Nick" <nmsmith65 gmail.com> writes:
 What about just shipping a fully automated fix-up tool when 
 trivial but major breaking changes happen?
I'd definitely vote for a fix-up tool. I think it's fair on developers to make a change for consistency of the language whilst providing a mostly automated means to do a one-off fix. It'd be a small onus on a tiny subset of developers to sort out any extraordinary edge cases. The alternative is to slowly build up a menagerie of quirks that put us on the same path as C++. I'm sure many of us would spend a bit of time writing a clever tool if it means we can rid ourselves of inconsistencies before they breed like rabbits. And it's better to make a change in the near term than to consider it in 5 years time.
Nov 10 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
 The alternative is to slowly build up a menagerie of quirks 
 that put us on the same path as C++.
It seems that a buildup of quirks is underway as is evidenced by this discussion. The other solution is to at some point place a freeze on D2 with bug support only and move on to D3 with at least the worse of the known baggage removed. There are of course disadvantages and dangers with doing that, but it is an option. Ultimately if we try and keep everyone happy, at some point no one will be happy, so I think it's worth trying to find good solutions to enable the language to evolve in ways that can leave baggage from the past behind. --rt
Nov 10 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/10/13 3:39 PM, Rob T wrote:
 On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
 The alternative is to slowly build up a menagerie of quirks that put
 us on the same path as C++.
It seems that a buildup of quirks is underway as is evidenced by this discussion. The other solution is to at some point place a freeze on D2 with bug support only and move on to D3 with at least the worse of the known baggage removed. There are of course disadvantages and dangers with doing that, but it is an option.
No. This is not negotiable. Andrei
Nov 10 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 11, 2013 00:39:04 Rob T wrote:
 On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
 The alternative is to slowly build up a menagerie of quirks
 that put us on the same path as C++.
It seems that a buildup of quirks is underway as is evidenced by this discussion. The other solution is to at some point place a freeze on D2 with bug support only and move on to D3 with at least the worse of the known baggage removed. There are of course disadvantages and dangers with doing that, but it is an option. Ultimately if we try and keep everyone happy, at some point no one will be happy, so I think it's worth trying to find good solutions to enable the language to evolve in ways that can leave baggage from the past behind.
I think that it's naive to think that any serious language will avoid building up quirks and rough corners over time. You never get a language completely right (assuming that's even possible), and you only have so long after you create it to tweak stuff before it has to be more or less set in stone for it to be useable in the real world. Some stuff can be tweaked over time even after you're "stable," but you have to be very careful about it in order to minimize if not outright eliminate breakage. And the longer that a language is around, the more unwieldy it's going to get. Either it doesn't innovate at all and avoids building up more quirks, or it innovates and ends up with quirks as it adds and adjusts stuff after the fact. Eventually, the baggage from those quirks will be big enough that if you want to get rid of them, you'll be forced to either create a new language or to create a new version of the language which breaks backwards compatiibiity, which tends to be little different from just creating a new language. I really don't think that there's any way around that. D doesn't have all of the baggage of C and C++, because it's a new language which breaks compatibility with them, but it's building up its own quirks and mistakes and will continue to do so. We should do our best to minimize that, but I really don't think that there's any way avoid it completely. Languages _need_ to be more or less set in stone in order to be useable in the real world, and if you set them in stone, then you're going to end up with quirks and baggage when you add onto them later. That's just the way it is, and I think that anyone who thinks that D can avoid the same fate as C++ in that regard is being naive. Some day, there will be a D++, or a D3, or an E, or whatever for the same reason that we created D instead of continuing to use C++ and for the same reason that the python developers created python 3. But that's a _long_ way off. First, we have to make D2 work, and part of that means living with at least some of the mistakes that we've made and quirks that the language has acquired. And honestly, many of those are tradeoffs that I don't think that anyone has a good solution for at this point anyway. So, even if someone went and created D3 right now, I don't think that it would be appreciably better than D2 (in some regards maybe, but not enough to be worth the split that that would cause to the code and to the community). - Jonathan M Davis
Nov 10 2013
next sibling parent "Michael" <pr m1xa.com> writes:
You're right.

Also the D have a deprecation-notice-period that adds stability 
in comparison to just-in-repo changes.
Nov 11 2013
prev sibling parent "Rob T" <alanb ucora.com> writes:
I don't disagree with what you are saying, however I think it is 
healthy to always question the status quo and continue to try and 
find innovative ways to destroy established thinking that 
otherwise limits what can and cannot be done.

Currently, the most acceptable methods discussed in here of 
moving forward and getting rid of old inadequate concepts, seems 
to be through very carefully considered deprecation and the 
implementing of automated methods for updating old code to 
conform to newer and better standards.

We do have deprecation, but so far I have not seen methods of 
automated updates so maybe that's something worth considering 
down the road.

I do have some experience with automating updates of old code. 
Certain databases I've worked on required updates, and the only 
foolproof method of doing it was to automate the process as much 
as possible, and I've had very good success doing it that way. 
Manually updating code is very stressful and error prone, no one 
wants to do it, but if you can click on a button and have the 
code updated for you without concern that it will fail miserably 
or cause weird side effects, upgrades become a good thing instead 
of a bad thing.

--rt

On Monday, 11 November 2013 at 00:13:34 UTC, Jonathan M Davis 
wrote:
 On Monday, November 11, 2013 00:39:04 Rob T wrote:
 On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
 The alternative is to slowly build up a menagerie of quirks
 that put us on the same path as C++.
It seems that a buildup of quirks is underway as is evidenced by this discussion. The other solution is to at some point place a freeze on D2 with bug support only and move on to D3 with at least the worse of the known baggage removed. There are of course disadvantages and dangers with doing that, but it is an option. Ultimately if we try and keep everyone happy, at some point no one will be happy, so I think it's worth trying to find good solutions to enable the language to evolve in ways that can leave baggage from the past behind.
I think that it's naive to think that any serious language will avoid building up quirks and rough corners over time. You never get a language completely right (assuming that's even possible), and you only have so long after you create it to tweak stuff before it has to be more or less set in stone for it to be useable in the real world. Some stuff can be tweaked over time even after you're "stable," but you have to be very careful about it in order to minimize if not outright eliminate breakage. And the longer that a language is around, the more unwieldy it's going to get. Either it doesn't innovate at all and avoids building up more quirks, or it innovates and ends up with quirks as it adds and adjusts stuff after the fact. Eventually, the baggage from those quirks will be big enough that if you want to get rid of them, you'll be forced to either create a new language or to create a new version of the language which breaks backwards compatiibiity, which tends to be little different from just creating a new language. I really don't think that there's any way around that. D doesn't have all of the baggage of C and C++, because it's a new language which breaks compatibility with them, but it's building up its own quirks and mistakes and will continue to do so. We should do our best to minimize that, but I really don't think that there's any way avoid it completely. Languages _need_ to be more or less set in stone in order to be useable in the real world, and if you set them in stone, then you're going to end up with quirks and baggage when you add onto them later. That's just the way it is, and I think that anyone who thinks that D can avoid the same fate as C++ in that regard is being naive. Some day, there will be a D++, or a D3, or an E, or whatever for the same reason that we created D instead of continuing to use C++ and for the same reason that the python developers created python 3. But that's a _long_ way off. First, we have to make D2 work, and part of that means living with at least some of the mistakes that we've made and quirks that the language has acquired. And honestly, many of those are tradeoffs that I don't think that anyone has a good solution for at this point anyway. So, even if someone went and created D3 right now, I don't think that it would be appreciably better than D2 (in some regards maybe, but not enough to be worth the split that that would cause to the code and to the community). - Jonathan M Davis
Nov 12 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-11 00:08, Nick wrote:

 I'd definitely vote for a fix-up tool. I think it's fair on developers
 to make a change for consistency of the language whilst providing a
 mostly automated means to do a one-off fix. It'd be a small onus on a
 tiny subset of developers to sort out any extraordinary edge cases.
Apple has created several fix-up tools, either built-in to Xcode or Clang. It's mostly for moving code to using a more modern style Objective-C, that is ARC, new syntax for arrays, dictionaries and so on. -- /Jacob Carlborg
Nov 10 2013
prev sibling parent =?utf-8?Q?Daniel_Koz=C3=A1k?= <kozzi11 gmail.com> writes:
 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.
Nov 07 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
 And gain what? You force everyone to change their code for 
 essentially zero
 benefit.

 - Jonathan M Davis
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. --rt
Nov 06 2013
parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Nov 06 2013
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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 :'(
Nov 06 2013
next sibling parent reply "eles" <eles eles.com> writes:
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?
Nov 07 2013
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Nov 07 2013
prev sibling next sibling parent reply "WasThere" <WasThere example.com> writes:
Anyway adding or removing   will cause code breakage,
but leaving   for UDAs it's better. It will be beautiful in words 
of consistency.
Nov 07 2013
parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Nov 07 2013
parent "eles" <eles eles.com> writes:
On Thursday, 7 November 2013 at 09:29:39 UTC, Daniel Kozak wrote:
 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
This is important. I think the least painful path to achieve both consistency and minimum brakage would be to introduce different prefixes for built-in attributes and for user-defined attributes, for example: #private myattr This still let open the question of a different kind of grouping attributes (eg wrt their influence on mangling) but the latter, at least concerning the ABI, should be less a concern for the developer, but for the implementor. OTOH, there is some way of distinguishing between UDA and non-UDA: their qualification name. Maybe this could be extended some way (eg prefix all attributes with , but someway give them names with categories): abi!nogc Yes, it's a bit ugly. Finally, one suggestion about those long chains of "pure safe nothrow" Could mega-attributes be defined? alias myAttr=(pure safe nothrow); myAttr myFunction() {} ? Some might even be pre-defined in std so that could be part of the standard. PS public, private and so on have strong C++ history where they are written without and this may introduce a bias in our view.
Nov 08 2013
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
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:
 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 :'(
In the contrary, ensuring stability gives it a chance to be accepted/supported by major industrial players (like Facebook for instance), which would help boost the language's development and ecosystem.
Nov 09 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-07 01:13, Shammah Chancellor wrote:
 My understanding is that   attributes were for used-defined behavior
 only.   Pure and nothrow, since the compiler implements behavior on
 those keywords, do not have the   sign.   So, why is  safe,  safe, and
 not just "safe".

 On the basis that  attributes should not have compiler defined
 behavior.   Please take off the   from the  safe.   This would apply to
  trusted as well.
The reason is basically that they wanted a new scope for keywords. Making it easy to introduce new keywords without breaking existing code. This worked until UDA's where introduce, because now " foo" is legal. Now we're back at square one, although we do have UDA's, which are nice :)
 Also,  I think that having UDAs (user defined attributes) be freeform,
 and not a class following some interface is asking for trouble.  It
 makes them hard to use reflection with, and it also causes the potential
 for modules to use the same literal for different purposes. I think C#
 has this right.
I completely agree. The recommendation is to not use literals but instead create a new type for the UDA: enum foo; foo void bar () { } Or: struct foo { string name; } foo("asd") void bar () { } This way you can uniquely identify a UDA using its fully qualified name. On top of that I'm using some helper functions which forces me to explicitly mark any UDA with a special UDA. enum attribute; attribute enum foo; attribute struct foo { string name; } foo("asd") void bar () { } getAttributes!(bar); By default "getAttributes" will only return attributes which themselves have the attribute UDA attached to them. See https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Attribute.d -- /Jacob Carlborg
Nov 06 2013
prev sibling next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Thursday, 7 November 2013 at 00:13:49 UTC, Shammah Chancellor 
wrote:
 My understanding is that   attributes were for used-defined 
 behavior only.   Pure and nothrow, since the compiler 
 implements behavior on those keywords, do not have the   sign.
  So, why is  safe,  safe, and not just "safe".

 On the basis that  attributes should not have compiler defined 
 behavior.   Please take off the   from the  safe.   This would 
 apply to  trusted as well.
Remove from safe, system and trust or property would lead to add more keywords, which would be unpleasant (break existing code and so on). More better would be to add sign to the others ( nothrow, immutable and pure).
 ...not a class following some interface is asking for trouble.
What exactly do you mean?
Nov 06 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 07 2013
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
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 :)
Nov 07 2013
prev sibling parent "Michael" <pr m1xa.com> writes:
After all, we have a language philosophy and we can have a some 
planning with breaking changes.
Facebook, no doubt, it is good. But "stability" in such way will 
cause that the D will became another C++'s reincarnation in case 
without consistency.

As example of "oh, sh*t it's changed", please, remember 
add/removing in github repo a new syntax of "alias this" in new 
way like alias aliasName = symbol.

 / safe/ UDA -> causes dissonance over 9000% !!!


Sorry for this Inglesh.
Nov 10 2013