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.
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 

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

 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

 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

 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

 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

 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

 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

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

 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

 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

 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