www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's left to do for a stable D2?

reply Jason House <jason.james.house gmail.com> writes:
Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left?
Jan 21 2010
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


This page[1] has been getting regular updates, so it should do a good
job answering the question.

1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
Jan 21 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jesse Phillips:

 This page[1] has been getting regular updates, so it should do a good
 job answering the question.
 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


Most things on that page seems OK and not too much complex to understand. There
are two things in that page that I think need more discussion, because I don't
understand them or I don't see their need:
- Remove struct initializers.
- Make array literals immutable.
So I'd like an explanation of what the first means, and why body are
useful/necessary.

Bye,
bearophile
Jan 21 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 22 Jan 2010 08:50:17 +0100, bearophile <bearophileHUGS lycos.com>  
wrote:


 Jesse Phillips:

 This page[1] has been getting regular updates, so it should do a good
 job answering the question.
 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 Most things on that page seems OK and not too much complex to  
 understand. There are two things in that page that I think need more  
 discussion, because I don't understand them or I don't see their need:
 - Remove struct initializers.


Struct initializers on the C form:
   struct S { int n; }
   S s = { 4 };
No need for them when we have this:
   S s = S( 4 );
and static opCall for those special occasions.

This cleans up the language, and makes some things somewhat easier
(e.g., what is the type of { 4, "Hi!" }?


 - Make array literals immutable.


Currently, string literals are immutable, but no other array literals are:
   auto s = "Foo!"; // typeof( s ) == immutable(char)[]
   auto i = [ 1, 2, 3, 4 ]; // typeof( i ) == int[]

Literals are allocated in the static data segment, and thus should be
immutable.

-- 
Simen
Jan 22 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Thank you for your answers Simen kjaeraas.


No need for them when we have this: S s = S( 4 );<


If you have to initialize an array of many structs you have to repeat the name
of the struct many times, this is redundant, and takes more space (and if you
don't use an IDE it needs more time to type):

struct Vector2 { double x, y; }

Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, {5,6},
{6,7},
                   {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, {13,14},
                   {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}];

Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), Vector2(3,4),
                   Vector2(4,5), Vector2(5,6), Vector2(6,7), Vector2(7,8),
                   Vector2(8,9), Vector2(9,10), Vector2(10,11), Vector2(11,12),
                   Vector2(12,13), Vector2(13,14), Vector2(14,15),
Vector2(15,16),
                   Vector2(16,17), Vector2(17,18), Vector2(18,19),
Vector2(19,20)];

void main() {}



Literals are allocated in the static data segment, and thus should be
immutable.<


In Python I am used to modify the contents of array (list) literals, for
example I can initialize them to some values and then change them. So I'd like
array literals to be mutable, but I can live with them being immutable and dup
them where necessary.

There are times in D code where I write:

foreach (direction; [[-1,+0],[+0,-1],[+1,+0],[+0,+1]]) { ...

Where in a similar situation in Python I write (this bit of pattern matching is
very handy, but D devs seems not interested in this):

for sx, sy in [[-1,+0],[+0,-1],[+1,+0],[+0,+1]]: ...

Currently ldc compiles that line of D1 code badly (creating a new array of all
the directions in each loop cycle, ugly), with immutable literals there is
never a risk of doing:

foreach (ref direction; [[-1,+0],[+0,-1],[+1,+0],[+0,+1]]) { ...

so the array initialization can surely be moved out of the loop (another small
problem is that in D2 those little inner length-2 arrays are dynamic arrays,
that's not much efficient).

Bye,
bearophile
Jan 22 2010
next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Thank you for your answers Simen kjaeraas.
 

 No need for them when we have this: S s = S( 4 );<


 
 If you have to initialize an array of many structs you have to repeat the name
of the struct many times, this is redundant, and takes more space (and if you
don't use an IDE it needs more time to type):
 
 struct Vector2 { double x, y; }
 
 Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, {5,6},
{6,7},
                    {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, {13,14},
                    {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}];
 
 Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), Vector2(3,4),
                    Vector2(4,5), Vector2(5,6), Vector2(6,7), Vector2(7,8),
                    Vector2(8,9), Vector2(9,10), Vector2(10,11), Vector2(11,12),
                    Vector2(12,13), Vector2(13,14), Vector2(14,15),
Vector2(15,16),
                    Vector2(16,17), Vector2(17,18), Vector2(18,19),
Vector2(19,20)];
 
 void main() {}


That's interesting. I would tend to use a function to initialize such 
things, though, so I suspect such use cases are quite rare. Note that 
C-style struct initializers add a lot of complexity to the language.



 Literals are allocated in the static data segment, and thus should be
immutable.<


 
 In Python I am used to modify the contents of array (list) literals, for
example I can initialize them to some values and then change them. So I'd like
array literals to be mutable, but I can live with them being immutable and dup
them where necessary.


Currently, any use of array literals in D is a performance disaster.
Two days ago, I found that by changing one line of code in my app from:
immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128];
into
static immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128];

my entire app became about 5 times faster. That is ridiculous.
And such a clumsy syntax for something so simple.
Jan 22 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 bearophile wrote:

 Thank you for your answers Simen kjaeraas.


 No need for them when we have this: S s = S( 4 );<


 If you have to initialize an array of many structs you have to repeat 
 the name of the struct many times, this is redundant, and takes more 
 space (and if you don't use an IDE it needs more time to type):

 struct Vector2 { double x, y; }

 Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5}, 
 {5,6}, {6,7},
                    {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13}, 
 {13,14},
                    {14,15}, {15,16}, {16,17}, {17,18}, {18,19}, {19,20}];

 Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3), 
 Vector2(3,4),
                    Vector2(4,5), Vector2(5,6), Vector2(6,7), 
 Vector2(7,8),
                    Vector2(8,9), Vector2(9,10), Vector2(10,11), 
 Vector2(11,12),
                    Vector2(12,13), Vector2(13,14), Vector2(14,15), 
 Vector2(15,16),
                    Vector2(16,17), Vector2(17,18), Vector2(18,19), 
 Vector2(19,20)];

 void main() {}


 
 That's interesting. I would tend to use a function to initialize such 
 things, though, so I suspect such use cases are quite rare. Note that 
 C-style struct initializers add a lot of complexity to the language.
 
 

 Literals are allocated in the static data segment, and thus should be 
 immutable.<


 In Python I am used to modify the contents of array (list) literals, 
 for example I can initialize them to some values and then change them. 
 So I'd like array literals to be mutable, but I can live with them 
 being immutable and dup them where necessary.


 
 Currently, any use of array literals in D is a performance disaster.
 Two days ago, I found that by changing one line of code in my app from:
 immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128];
 into
 static immutable int [] setbits = [ 1, 2, 4, 8, 16, 32, 64, 128];
 
 my entire app became about 5 times faster. That is ridiculous.
 And such a clumsy syntax for something so simple.


Is this is bugzilla yet? FWIW I also submitted a related performance bug.

Andrei
Jan 22 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Fri, 22 Jan 2010 15:27:02 -0500, bearophile wrote:


 Thank you for your answers Simen kjaeraas.
 

No need for them when we have this: S s = S( 4 );<


 
 If you have to initialize an array of many structs you have to repeat
 the name of the struct many times, this is redundant, and takes more
 space (and if you don't use an IDE it needs more time to type):
 
 struct Vector2 { double x, y; }
 
 Vector2[] data1 = [{1,2}, {3,4}, {0,1}, {1,2}, {2,3}, {3,4}, {4,5},
 {5,6}, {6,7},
                    {7,8}, {8,9}, {9,10}, {10,11}, {11,12}, {12,13},
                    {13,14}, {14,15}, {15,16}, {16,17}, {17,18}, {18,19},
                    {19,20}];
 
 Vector2[] data2 = [Vector2(0,1), Vector2(1,2), Vector2(2,3),
 Vector2(3,4),
                    Vector2(4,5), Vector2(5,6), Vector2(6,7),
                    Vector2(7,8), Vector2(8,9), Vector2(9,10),
                    Vector2(10,11), Vector2(11,12), Vector2(12,13),
                    Vector2(13,14), Vector2(14,15), Vector2(15,16),
                    Vector2(16,17), Vector2(17,18), Vector2(18,19),
                    Vector2(19,20)];
 
 void main() {}


I'd use something like this in higher level languages™:

  case class Vector[T](x: T, y: T)

  val pairs = List( (1,2), (3,4), (0,1), (2,3), (3,4), (4,5) )

  val vectors = pairs map { case (a:Int, b:Int) => Vector(a,b) }

or

  class Vector[T](x: T, y: T) { def this(xy: (T,T)) = this(xy._1, xy._2) }

  val pairs = List( (1,2), (3,4), (0,1), (2,3), (3,4), (4,5) )

  val vectors = pairs map (new Vector(_))
Jan 23 2010
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 22 Jan 2010 21:27:02 +0100, bearophile <bearophileHUGS lycos.com=

  =


wrote:


 Thank you for your answers Simen kjaeraas.


 No need for them when we have this: S s =3D S( 4 );<


 If you have to initialize an array of many structs you have to repeat =


 =


 the name of the struct many times, this is redundant, and takes more  =



 space (and if you don't use an IDE it needs more time to type):


Use a local alias.

void foo( ) {
   alias StructWithHorriblyLongAndComplicatedName =E0=BA=95;
   auto s =3D [ =E0=BA=95( 1, "a" ), =E0=BA=95( 2, "b" ), =E0=BA=95( 3, =
"c" ) ];
}

-- =

Simen
Jan 23 2010
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Jesse Phillips Wrote:


 Jason House wrote:
 

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 
 This page[1] has been getting regular updates, so it should do a good
 job answering the question.
 
 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


I believe most "future directions" will be D3 or beyond. I'm pretty certain
that Andrei wants TDPL to match D2. All but one chapter has been written, and
TDPL related bugs have gotten priority. There should be very few feature
changes between now and D2 finalization.

Andrei, Walter, Sean, can you comment?
Jan 22 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Jesse Phillips Wrote:
 

 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 
 I believe most "future directions" will be D3 or beyond. I'm pretty certain
that Andrei wants TDPL to match D2. All but one chapter has been written, and
TDPL related bugs have gotten priority. There should be very few feature
changes between now and D2 finalization.
 
 Andrei, Walter, Sean, can you comment?


You mean the list "Known D2.0, Language"? Here's what I think (Walter is 
the ultimate go-to person):



D2



D2



D2



We have a design that partially resolves it. Steve Schveighoffer has 
implemented it.



I don't think they'll be removed, but TDPL doesn't mention them.



D2



Dunno



D2



Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature 
stays,


Andrei
Jan 22 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Andrei Alexandrescu wrote:

 We have a design that partially resolves it. Steve Schveighoffer has 
 implemented it.


What I meant here is: Steve has implemented the design in addition to 
participating to it.

Andrei
Jan 22 2010
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 22 Jan 2010 11:21:09 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Jason House wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating  
 std.thread(?), and Walter's been fixing forward reference and CTFE  
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1.  
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


  I believe most "future directions" will be D3 or beyond. I'm pretty  
 certain that Andrei wants TDPL to match D2. All but one chapter has  
 been written, and TDPL related bugs have gotten priority. There should  
 be very few feature changes between now and D2 finalization.
  Andrei, Walter, Sean, can you comment?


 You mean the list "Known D2.0, Language"? Here's what I think (Walter is  
 the ultimate go-to person):


 opIndexAssign!("*").

 D2



 D2



 D2



 We have a design that partially resolves it. Steve Schveighoffer has  
 implemented it.



 I don't think they'll be removed, but TDPL doesn't mention them.



 D2



 Dunno



 D2



 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature  
 stays,


What about propagating qualifiers to the return type (i.e. inout)?  I  
think that is a major change and is in the book.  It's currently partially  
implemented, but it does not work.

-Steve
Jan 22 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 On Fri, 22 Jan 2010 11:21:09 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Jason House wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


  I believe most "future directions" will be D3 or beyond. I'm pretty 
 certain that Andrei wants TDPL to match D2. All but one chapter has 
 been written, and TDPL related bugs have gotten priority. There 
 should be very few feature changes between now and D2 finalization.
  Andrei, Walter, Sean, can you comment?


 You mean the list "Known D2.0, Language"? Here's what I think (Walter 
 is the ultimate go-to person):


 opIndexAssign!("*").

 D2



 D2



 D2



 We have a design that partially resolves it. Steve Schveighoffer has 
 implemented it.



 I don't think they'll be removed, but TDPL doesn't mention them.



 D2



 Dunno



 D2



 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature 
 stays,


 
 What about propagating qualifiers to the return type (i.e. inout)?  I 
 think that is a major change and is in the book.  It's currently 
 partially implemented, but it does not work.
 
 -Steve


D2

Andrei
Jan 22 2010
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-01-22 11:21:09 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:



 
 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature stays,


Agree. That one must go.

At the very list it should be an error if it shadows any other symbol, 
but it'd be better if it just goes.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 22 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 1/22/10 17:21, Andrei Alexandrescu wrote:

 Jason House wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 I believe most "future directions" will be D3 or beyond. I'm pretty
 certain that Andrei wants TDPL to match D2. All but one chapter has
 been written, and TDPL related bugs have gotten priority. There should
 be very few feature changes between now and D2 finalization.

 Andrei, Walter, Sean, can you comment?


 You mean the list "Known D2.0, Language"? Here's what I think (Walter is
 the ultimate go-to person):


 opIndexAssign!("*").

 D2



 D2



 D2



 We have a design that partially resolves it. Steve Schveighoffer has
 implemented it.



 I don't think they'll be removed, but TDPL doesn't mention them.



 D2



 Dunno



 D2



 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature
 stays,


 Andrei


What about the uniform function call syntax ?
Jan 23 2010
next sibling parent retard <re tard.com.invalid> writes:
Sat, 23 Jan 2010 12:00:32 +0100, Jacob Carlborg wrote:


 What about the uniform function call syntax ?


It might require more useless bikeshedding before anything can be decided.
Jan 23 2010
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Jan 23, 2010 at 12:00:32PM +0100, Jacob Carlborg wrote:

 What about the uniform function call syntax ?


Yes, please!


-- 
Adam D. Ruppe
http://arsdnet.net
Jan 23 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jacob Carlborg wrote:

 On 1/22/10 17:21, Andrei Alexandrescu wrote:

 Jason House wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 I believe most "future directions" will be D3 or beyond. I'm pretty
 certain that Andrei wants TDPL to match D2. All but one chapter has
 been written, and TDPL related bugs have gotten priority. There should
 be very few feature changes between now and D2 finalization.

 Andrei, Walter, Sean, can you comment?


 You mean the list "Known D2.0, Language"? Here's what I think (Walter is
 the ultimate go-to person):


 opIndexAssign!("*").

 D2



 D2



 D2



 We have a design that partially resolves it. Steve Schveighoffer has
 implemented it.



 I don't think they'll be removed, but TDPL doesn't mention them.



 D2



 Dunno



 D2



 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature
 stays,


 Andrei


 
 What about the uniform function call syntax ?


Far as I know it's already in, with bugs.

Andrei
Jan 23 2010
parent Jacob Carlborg <doob me.com> writes:
On 1/23/10 18:50, Andrei Alexandrescu wrote:

 Jacob Carlborg wrote:

 On 1/22/10 17:21, Andrei Alexandrescu wrote:

 Jason House wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1.
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 I believe most "future directions" will be D3 or beyond. I'm pretty
 certain that Andrei wants TDPL to match D2. All but one chapter has
 been written, and TDPL related bugs have gotten priority. There should
 be very few feature changes between now and D2 finalization.

 Andrei, Walter, Sean, can you comment?


 You mean the list "Known D2.0, Language"? Here's what I think (Walter is
 the ultimate go-to person):


 opIndexAssign!("*").

 D2



 D2



 D2



 We have a design that partially resolves it. Steve Schveighoffer has
 implemented it.



 I don't think they'll be removed, but TDPL doesn't mention them.



 D2



 Dunno



 D2



 Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature
 stays,


 Andrei


 What about the uniform function call syntax ?


 Far as I know it's already in, with bugs.

 Andrei


I've not seen it being mentioned at all and I can't get it to work:

void foo (Object o) { }

void main ()
{
	Object o = new Object;
	o.foo();
}

Compiling the above with dmd trunk results in:
main.d(8): Error: no property 'foo' for type 'object.Object'

Looking at 
http://www.dsource.org/projects/dmd/browser/trunk/src/expression.c#L6483 
it seems it's not implemented.
Jan 24 2010
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Jason House Wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


D2 seems to be close to be declared stable. I would also like to know if 64 bit
support is going to be the next thing on the list? In my opinion it is much
more important than any feature (AST macros, annotations etc). MS is pushing
Windows 7 in 64 bit version. It is the same case with Apple operation systems
and Linux. Many people refuse to use D2 and fall back to ldc just for this
reason.
Jan 22 2010
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 22/01/10 10:42, Eldar Insafutdinov wrote:

 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.


I'd have to agree, myself being one of those users.
Jan 24 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Eldar Insafutdinov wrote:

 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.



I'm very aware of the importance of 64 bits, and it's next after D2 is 
complete.
Jan 24 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 25 Jan 2010 02:43:28 +0100, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Eldar Insafutdinov wrote:

 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.



 I'm very aware of the importance of 64 bits, and it's next after D2 is  
 complete.


Awesome! D just keeps getting better.

-- 
Simen
Jan 24 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Eldar Insafutdinov wrote:

 D2 seems to be close to be declared stable. I would also like to know
 if 64 bit support is going to be the next thing on the list? In my
 opinion it is much more important than any feature (AST macros,
 annotations etc). MS is pushing Windows 7 in 64 bit version. It is
 the same case with Apple operation systems and Linux. Many people
 refuse to use D2 and fall back to ldc just for this reason.


 I'm very aware of the importance of 64 bits, and it's next after D2 is
 complete.


Just out of curiosity, how hard is 64-bit to implement given that you already
have
a 32-bit compiler?
Jan 24 2010
next sibling parent Trass3r <un known.com> writes:
Am 25.01.2010, 03:08 Uhr, schrieb dsimcha <dsimcha yahoo.com>:

 Just out of curiosity, how hard is 64-bit to implement given that you  
 already have a 32-bit compiler?


According to LuaJIT, a 64Bit code generator isn't that easy even if you  
already have a 32Bit one.
http://luajit.org/sponsors.html etc.
Jan 24 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 Just out of curiosity, how hard is 64-bit to implement given that you already
have
 a 32-bit compiler?


Shouldn't be that bad. After all, the current code generator survived 
going from 16 to 32 bits with about 90% of it unchanged.

Probably a lot more work will go into writing the inline assembler.

I'll have a big problem with the (nonexistent) 64 bit linker on Windows, 
and a lesser problem with the nonexistent debugger and librarian. That 
means that the first 64 bit dmd will be for Linux/OSX.
Jan 24 2010
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 ...
 I'll have a big problem with the (nonexistent) 64 bit linker on Windows,
 and a lesser problem with the nonexistent debugger and librarian. That
 means that the first 64 bit dmd will be for Linux/OSX.


Maybe it's time to switch to using the GNU tools on WindoMaybe it's time
to switch to using the GNU tools on WindoMaybe it's-vwwwip

Sorry, broken record.

:P
Jan 24 2010
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 24 Jan 2010 21:59:38 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:


 dsimcha wrote:

 Just out of curiosity, how hard is 64-bit to implement given that you  
 already have
 a 32-bit compiler?


 Shouldn't be that bad. After all, the current code generator survived  
 going from 16 to 32 bits with about 90% of it unchanged.


But don't 16-bit and 32-bit x86 have the same number of registers, while  
x86-64 doubled them? Which should result in ABI changes, etc in addition  
to optimizer changes. Also, FWIW, according to Wikipedia, position  
independent code is also easier and they threw out some old instructions.
Jan 24 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Jacques wrote:

 But don't 16-bit and 32-bit x86 have the same number of registers, while 
 x86-64 doubled them? Which should result in ABI changes, etc in addition 
 to optimizer changes.


No optimizer changes, ABI changes are minor.
Jan 24 2010
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 01/24/2010 08:59 PM, Walter Bright wrote:

 I'll have a big problem with the (nonexistent) 64 bit linker on Windows,
 and a lesser problem with the nonexistent debugger and librarian. That
 means that the first 64 bit dmd will be for Linux/OSX.


Not that I know anything about GSoC, but do you think such a project 
make a good target for Google summer of code?
Jan 24 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:

 Not that I know anything about GSoC, but do you think such a project 
 make a good target for Google summer of code?


I know less than nothing about that.
Jan 24 2010
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 24 de enero a las 20:33 me escribiste:

 Ellery Newcomer wrote:

Not that I know anything about GSoC, but do you think such a
project make a good target for Google summer of code?


 
 I know less than nothing about that.


The backend is not free, only FLOSS projects can apply to GSoC.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Jan 25 2010
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Jesse Phillips Wrote:


 Jason House wrote:
 

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 
 This page[1] has been getting regular updates, so it should do a good
 job answering the question.
 
 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections



From this list: default struct constructors?
Jan 23 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:
 

 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 
 
 From this list: default struct constructors?


Walter doesn't want. This will go down as one of the larger language 
incapabilities.

Andrei
Jan 23 2010
next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Andrei Alexandrescu Wrote:


 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:
 

 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 
 
 From this list: default struct constructors?


 
 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.
 
 Andrei


Sigh...
Jan 23 2010
parent reply grauzone <none example.net> writes:
Eldar Insafutdinov wrote:

 Andrei Alexandrescu Wrote:
 

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.

 Andrei


 
 Sigh...


Why can't you just use opCall?
Jan 23 2010
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
grauzone Wrote:


 Eldar Insafutdinov wrote:

 Andrei Alexandrescu Wrote:
 

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.

 Andrei


 
 Sigh...


 
 Why can't you just use opCall?


It's ugly, doesn't work sometimes and is inconsistent with other constructors.
Jan 24 2010
parent reply grauzone <none example.net> writes:
Eldar Insafutdinov wrote:

 grauzone Wrote:
 

 Eldar Insafutdinov wrote:

 Andrei Alexandrescu Wrote:


 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.

 Andrei


 Sigh...


 Why can't you just use opCall?


 
 It's ugly, doesn't work sometimes and is inconsistent with other constructors.


Why doesn't it work, bugs?
Use opCall instead of constructor in the other cases too?
Are there cases where ctors can do something opCall can't? I thought 
constructors were only added for symmetry with dtors.
Jan 24 2010
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 24 Jan 2010 15:12:47 +0100, grauzone <none example.net> wrote:


 Eldar Insafutdinov wrote:

 grauzone Wrote:


 Eldar Insafutdinov wrote:

 Andrei Alexandrescu Wrote:


 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating  
 std.thread(?), and Walter's been fixing forward reference and  
 CTFE bugs. What's left?


 This page[1] has been getting regular updates, so it should do a  
 good
 job answering the question.

 1.  
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language  
 incapabilities.

 Andrei


 Sigh...


 Why can't you just use opCall?


  It's ugly, doesn't work sometimes and is inconsistent with other  
 constructors.


 Why doesn't it work, bugs?
 Use opCall instead of constructor in the other cases too?
 Are there cases where ctors can do something opCall can't? I thought  
 constructors were only added for symmetry with dtors.


Take this for example:

struct S {
   int n;
   this( ) {
     n = random( );
   }
}

class C {
   S s;
}

In C++, 'new C( );' would call S's constructor, and initialize n to
some random number. opCall can do the same thing, but must be
explicitly called in C's constructor. This can be unacceptable for
libraries, at least.

-- 
Simen
Jan 24 2010
parent reply grauzone <none example.net> writes:
Simen kjaeraas wrote:

 On Sun, 24 Jan 2010 15:12:47 +0100, grauzone <none example.net> wrote:
 

 Eldar Insafutdinov wrote:

 grauzone Wrote:


 Eldar Insafutdinov wrote:

 Andrei Alexandrescu Wrote:


 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and 
 CTFE bugs. What's left?


 This page[1] has been getting regular updates, so it should do a 
 good
 job answering the question.

 1. 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections 


 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger 
 language incapabilities.

 Andrei


 Sigh...


 Why can't you just use opCall?


  It's ugly, doesn't work sometimes and is inconsistent with other 
 constructors.


 Why doesn't it work, bugs?
 Use opCall instead of constructor in the other cases too?
 Are there cases where ctors can do something opCall can't? I thought 
 constructors were only added for symmetry with dtors.


 
 Take this for example:
 
 struct S {
   int n;
   this( ) {
     n = random( );
   }
 }
 
 class C {
   S s;
 }
 
 In C++, 'new C( );' would call S's constructor, and initialize n to
 some random number. opCall can do the same thing, but must be
 explicitly called in C's constructor. This can be unacceptable for
 libraries, at least.
 


Yes, but ctors with empty argument list aren't coming to D anyway.
Jan 24 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
grauzone <none example.net> wrote:


 Yes, but ctors with empty argument list aren't coming to D anyway.


Yeah. That was kinda the point. We wants them, though.

-- 
Simen
Jan 24 2010
prev sibling next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 23 Jan 2010 18:51:19 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating  
 std.thread(?), and Walter's been fixing forward reference and CTFE  
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1.  
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


   From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language  
 incapabilities.

 Andrei


Might I inquire as to the reasoning for this?
Having no default struct constructors means one has to use classes if
such a capability is needed. Or of course, call an extra function! :p

-- 
Simen
Jan 23 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Simen kjaeraas wrote:

 On Sat, 23 Jan 2010 18:51:19 +0100, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections


   From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.

 Andrei


 
 Might I inquire as to the reasoning for this?
 Having no default struct constructors means one has to use classes if
 such a capability is needed. Or of course, call an extra function! :p


I wish the fix were as simple as that.

Andrei
Jan 23 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections



 From this list: default struct constructors?


 
 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.
 
 Andrei


What's the reason? Does he dislike the concept, or feel it's a 
implementation disaster, or something else?
Jan 24 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 Andrei Alexandrescu wrote:

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections



 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.

 Andrei


 
 What's the reason? Does he dislike the concept, or feel it's a 
 implementation disaster, or something else?


There are concerns about implementation difficulty and also about 
muddying other parts of the language, e.g. T.init may fail.

Andrei
Jan 24 2010
next sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 Don wrote:

 Andrei Alexandrescu wrote:

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1. 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections



 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language 
 incapabilities.

 Andrei


 What's the reason? Does he dislike the concept, or feel it's a 
 implementation disaster, or something else?


 
 There are concerns about implementation difficulty and also about 
 muddying other parts of the language, e.g. T.init may fail.


Good to know.
I think not having struct default constructors muddies some other 
things, though. For example, I don't see the point of struct invariants 
if it's possible to create a struct which doesn't obey the invariant.

I think the semantics of T.init are a bit doubtful already. Consider 
that floats default init to NaN, and char.init is not a valid UTF 
character. I don't think the existing T.init is trouble-free.
Jan 24 2010
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 24 Jan 2010 11:38:50 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Don wrote:

 Andrei Alexandrescu wrote:

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating  
 std.thread(?), and Walter's been fixing forward reference and CTFE  
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1.  
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections



 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language  
 incapabilities.

 Andrei


  What's the reason? Does he dislike the concept, or feel it's a  
 implementation disaster, or something else?


 There are concerns about implementation difficulty and also about  
 muddying other parts of the language, e.g. T.init may fail.

 Andrei


I strongly believe D should get rid of T.init; I hope I'll find some time  
to write a proposal and a rationale for it.
Jan 24 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 I strongly believe D should get rid of T.init; I hope I'll find some 
 time to write a proposal and a rationale for it.


Interesting. I suggest you hurry - now is the time!

Andrei
Jan 24 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Denis Koroskin (2korden gmail.com)'s article

 On Sun, 24 Jan 2010 11:38:50 +0300, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:

 Andrei Alexandrescu wrote:

 Eldar Insafutdinov wrote:

 Jesse Phillips Wrote:


 Jason House wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?


 This page[1] has been getting regular updates, so it should do a good
 job answering the question.

 1.
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections



 From this list: default struct constructors?


 Walter doesn't want. This will go down as one of the larger language
 incapabilities.

 Andrei


  What's the reason? Does he dislike the concept, or feel it's a
 implementation disaster, or something else?


 There are concerns about implementation difficulty and also about
 muddying other parts of the language, e.g. T.init may fail.

 Andrei


 I strongly believe D should get rid of T.init; I hope I'll find some time
 to write a proposal and a rationale for it.


Are you suggesting that we just get different syntax for it, or is the
suggestion
deeper?  I don't think there's any chance of us getting rid of default
initializers this late in the game, and I think it's absolutely essential for
generic code that there be an easy way to get the default initializer for a
type.
Jan 24 2010
parent Rainer Deyke <rainerd eldwood.com> writes:
dsimcha wrote:

 Are you suggesting that we just get different syntax for it, or is the
suggestion
 deeper?  I don't think there's any chance of us getting rid of default
 initializers this late in the game, and I think it's absolutely essential for
 generic code that there be an easy way to get the default initializer for a
type.


T init(T)() {
  T v;
  return v;
}


The nice thing about the above is that it also works when T has a
default constructor.


-- 
Rainer Deyke - rainerd eldwood.com
Jan 25 2010
prev sibling next sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Jason House Wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


is std.stream rewrite still on the list?
Jan 24 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Eldar Insafutdinov wrote:

 Jason House Wrote:
 

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 
 is std.stream rewrite still on the list?


Trying...

Andrei
Jan 24 2010
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 24 Jan 2010 14:58:13 +0100, Eldar Insafutdinov  
<e.insafutdinov gmail.com> wrote:


 Jason House Wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating  
 std.thread(?), and Walter's been fixing forward reference and CTFE  
 bugs. What's left?


 is std.stream rewrite still on the list?


I managed to read this as std.steam. Awesome, steampunk D!

-- 
Simen
Jan 24 2010
parent Bernard Helyer <b.helyer gmail.com> writes:
On 25/01/10 04:01, Simen kjaeraas wrote:

 On Sun, 24 Jan 2010 14:58:13 +0100, Eldar Insafutdinov
 <e.insafutdinov gmail.com> wrote:


 Jason House Wrote:


 Andrei's finishing his last TDPL chapter, Sean is updating
 std.thread(?), and Walter's been fixing forward reference and CTFE
 bugs. What's left?


 is std.stream rewrite still on the list?


 I managed to read this as std.steam. Awesome, steampunk D!


std.steam.gratuitousValves();
Jan 25 2010
prev sibling next sibling parent reply grauzone <none example.net> writes:
Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


Documentation. The Phobos docs are rather bad, and don't even include 
the core modules. Also there's std.thread, shouldn't it be core.thread?

You can't release D2 "on the masses" like that.
Jan 24 2010
next sibling parent Jason House <jason.james.house gmail.com> writes:
grauzone Wrote:


 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating std.thread(?), and
Walter's been fixing forward reference and CTFE bugs. What's left? 


 
 Documentation. The Phobos docs are rather bad, and don't even include 
 the core modules. Also there's std.thread, shouldn't it be core.thread?


Didn't someone start a wiki page in an attempt to revamp the Phobos docs? What
happened to that?
Jan 24 2010
prev sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 
 Documentation. The Phobos docs are rather bad, and don't even include 
 the core modules. Also there's std.thread, shouldn't it be core.thread?
 
 You can't release D2 "on the masses" like that.


It's only the language spec which is getting frozen, not the libraries.
TDPL intentionally doesn't say much at all about Phobos.
Jan 25 2010
parent reply grauzone <none example.net> writes:
Don wrote:

 grauzone wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 Documentation. The Phobos docs are rather bad, and don't even include 
 the core modules. Also there's std.thread, shouldn't it be core.thread?

 You can't release D2 "on the masses" like that.


 
 It's only the language spec which is getting frozen, not the libraries.
 TDPL intentionally doesn't say much at all about Phobos.


Well, you see, as TDPL is releases, there will be much attention on D, 
and people will go and try it out. Keep in mind that those people will 
know next to nothing about D. If the first what they'll experience is 
crashing on the chaotic documentation, that's going to be a major 
disappointment. It's like giving a birthday party without cake.
Jan 25 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:

 Don wrote:

 grauzone wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 Documentation. The Phobos docs are rather bad, and don't even include 
 the core modules. Also there's std.thread, shouldn't it be core.thread?

 You can't release D2 "on the masses" like that.


 It's only the language spec which is getting frozen, not the libraries.
 TDPL intentionally doesn't say much at all about Phobos.


 
 Well, you see, as TDPL is releases, there will be much attention on D, 
 and people will go and try it out. Keep in mind that those people will 
 know next to nothing about D. If the first what they'll experience is 
 crashing on the chaotic documentation, that's going to be a major 
 disappointment. It's like giving a birthday party without cake.


Expending a fraction of the energy spent in wringing hands on actually 
helping with the documentation would mark a definite improvement.

Andrei
Jan 25 2010
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:

 grauzone wrote:

 Don wrote:

 grauzone wrote:

 Jason House wrote:

 Andrei's finishing his last TDPL chapter, Sean is updating 
 std.thread(?), and Walter's been fixing forward reference and CTFE 
 bugs. What's left? 


 Documentation. The Phobos docs are rather bad, and don't even 
 include the core modules. Also there's std.thread, shouldn't it be 
 core.thread?

 You can't release D2 "on the masses" like that.


 It's only the language spec which is getting frozen, not the libraries.
 TDPL intentionally doesn't say much at all about Phobos.


 Well, you see, as TDPL is releases, there will be much attention on D, 
 and people will go and try it out. Keep in mind that those people will 
 know next to nothing about D. If the first what they'll experience is 
 crashing on the chaotic documentation, that's going to be a major 
 disappointment. It's like giving a birthday party without cake.


 
 Expending a fraction of the energy spent in wringing hands on actually 
 helping with the documentation would mark a definite improvement.
 
 Andrei



I'm not too worried about the quality of documentation, and as has been 
mentioned before, it's probably not necessary to finish Phobos before 
TDPL comes out.

What I think should be done, however, is to clear out the parts of 
Phobos you intend to remove or substantially rewrite.  First impressions 
matter, and I think it's better for a (potential) new user to be met 
with "this currently isn't available, but check back in a little while", 
rather than with a set of perhaps-not-so-well-designed modules that will 
disappear after some time anyway.

-Lars
Jan 25 2010
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Jason House wrote:

 What's left? 


Getting D1 finished first.  Why do people keep asking???

Stewart.
Jan 25 2010