www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Developing a plan for D2.0: Getting everything on the table

reply Don <nospam nospam.com> writes:
A lot of frustration has been expressed on the newgroup about lack of a 
clear public plan for D2.0. I don't think we're in a position to create 
a road-map. But, let's at least agree on which countries we'll probably 
visit before we reach our final destination <g>.

Everyone knows there are a multitude of significant bugs in Bugzilla, 
and most people have their pet list of minor language warts they hope 
will be removed. But there's also some earthquake issues that have huge 
implications. It's very disconcerting when some of them are introduced 
in a casual manner. I think it would reduce a lot of frustation in the 
community if we compiled an official list of the major ones. Here's a 
few I came up with:

- Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
- Multithreading (II): Will some form of message parsing be included?
- Operator overloading. "completely redone" (?)
- opImplicitCast
- is T[new] still going to happen?
- Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
- Unimplemented features -- safe D, contract inheritance.
- Andrei once said that he wants to get rid of new (!)
- The Tango license issue needs to be sorted to the extent that Andrei 
and Walter feel they can safely look at the Tango code; OR we can decide 
that's not going to happen, and change the strategy for the Tango/Phobos 
relationship.

The stuff on this list will either be implemented, or dropped. New 
things could be added to the list. But we can gauge our progress towards 
D2.0 by how rapidly the list shrinks with time.

Which other major issues have I missed? Things which, if they happen, 
will probably require major spec changes, major library redesign, or 
break large amounts of code. Let's get everything on the table.
Jul 14 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
Let's get everything on the table.<
Thank you for this thread, Don, recently I too have tried to start something like it :-)
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
Some other things that may be necessary for D2: - making D2 fitter for the LLVM back-end; - fixing and improving the import semantics; - separating arrays and slices? - removing "Substitution failure is not an error"? - maybe built-in rectangular arrays? Or a more flexible operator overload syntax to implement them. - maybe improving the data parallelism features. Bye, bearophile
Jul 14 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
bearophile wrote:
 - making D2 fitter for the LLVM back-end;
I've noticed you keep mentioning this. What exactly is it you mean by this? If you mean allowing the dmd front end to be identical in both dmd and ldc, I don't think that will ever happen (although getting it close should be possible). Putting together a patch to submit for dmd is on my to-do list for ldc2, I figured I'd wait for ldc2 to be in a more stable state before doing this though... No point submitting the patch when there's a nice chance it's going to change a lot as the (rather large) number of ICEs on valid D2 code drops (About 80% of Phobos2 causes an ICE currently. The rest compiles, but I doubt the code functions correctly, I didn't bother testing!). That said, merging newer frontends in the mean time would be a lot simpler if I put together a basic patch...
Jul 14 2009
prev sibling next sibling parent Nick B <nick.barbalich gmail.com> writes:
Don wrote:
 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
 
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
On July 09, Bartosz mentioned the following: "The bottom line of this post is that the current Thread object in D should be abandoned and replaced by a more primitive "spawn" function. If there are no serious objections, we are going to proceed with the rewrite." If think that its arguable that "the replacement of the current Thread object" is seperate from Multithreading (I & II) above. I think this should be clarified if this is part of D2.0
Jul 14 2009
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:
 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
FINALLY, there is someone who says "what can we do to make things better" instead of "what can we do to avoid near-certain doom". Thank you!
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
I seem to remember Andrei saying that not only does he want to redesign various (all?) parts of Phobos, there are also several modules which will be removed altogether. It would be nice to know which. -Lars
Jul 14 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Don wrote:
 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
 
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
I've put this list on the D wiki at: http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2 If it becomes complete enough, maybe it can go into the 'future' page in the next compiler release. (The future page says that 'array operations are planned but the details have not been worked out'. So it shouldn't be hard to improve on <g>).
Jul 14 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Don, el 14 de julio a las 11:53 me escribiste:
 A lot of frustration has been expressed on the newgroup about lack of a clear 
 public plan for D2.0. I don't think we're in a position to create a road-map. 
 But, let's at least agree on which countries we'll probably visit before we 
 reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, and most 
 people have their pet list of minor language warts they hope will be removed. 
 But there's also some earthquake issues that have huge implications. It's very 
 disconcerting when some of them are introduced in a casual manner. I think it 
 would reduce a lot of frustation in the community if we compiled an official 
 list of the major ones. Here's a few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei and 
 Walter feel they can safely look at the Tango code; OR we can decide that's
not 
 going to happen, and change the strategy for the Tango/Phobos relationship.
 The stuff on this list will either be implemented, or dropped. New
 things could be added to the list. But we can gauge our progress towards
 D2.0 by how rapidly the list shrinks with time.
I think DIPs can be helpful for this. You can track what of these features are dropped or accepted.
 Which other major issues have I missed? Things which, if they happen, will 
 probably require major spec changes, major library redesign, or break large 
 amounts of code. Let's get everything on the table.
There was a thread started by Andrei called -nogc that ended up suggesting some wrapping arround references that can be redefined to implmement reference counting or other tricks. Same for library implementation of associative and dynamic arrays. Will that happen? I don't think this will break anything, but it's a big change in both library and compiler (I think). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- There is no pain you are receding A distant ship, smoke on the horizon. You are only coming through in waves. Your lips move but I can't hear what you're saying.
Jul 14 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
This is a great initiative. Let me add a few small points.
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
I don't know. This is mostly up to Walter.
 - Multithreading (II): Will some form of message parsing be included?
(Passing I guess?) Yes, that's a definite yes.
 - Operator overloading. "completely redone" (?)
I think they should be redone. There are several issues: 1. Currently there's no provision for "expr1[expr2] = expr3", where is some binary operator. The opIndexAssign is more like the token presence that makes the absence felt even better. Scaling to opIndexAddAssign etc. seems to be overkill. 2. Operators = are dubious for classes because a class can't define "a = b" to mean the same as "a = a b". (I recall you were the first to note that.) I'd venture to think that many arithmetic operators don't make much sense for classes to start with. 3. There are types for which ++ or -- make sense but addition does not (e.g. STL-style iterators). 4. opXxx_r and opXxx can easily be ambiguous, as you noted in a recent thread. (I think that could be fixed with other means though.) 5. Defining operators asks for code duplication. Usually people want to define all arithmetic operators to forward to some member. That is unnecessarily verbose (see e.g. the implementation of std.variant which makes heroic efforts to counter that). Any other issues? (I feel I forgot a couple.) Maybe we can fix all of these by patching the existing system.
 - opImplicitCast
I think alias this should render that unnecesary.
 - is T[new] still going to happen?
I don't know.
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
The intent is to make all of I/O range-based such that e.g. files and other streams can be combined through std.range and std.algorithm in various ways.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
Why "!"? :o)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
 
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
There are many unfinished things, such as construction of immutable and const objects; a solid approach to unicity, moving, duplication, and marshaling; unification of overloading across templates and non-templates; I'll relay more as I remember. Andrei
Jul 14 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 14, 2009 at 12:42 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. You might want to use such a type transparently in place of any other integer type, i.e. as an array index. Something like "a[bi.toSizet()]" looks pretty awful. But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. It's probably an array or somesuch. opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
Jul 14 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. You might want to use such a type transparently in place of any other integer type, i.e. as an array index. Something like "a[bi.toSizet()]" looks pretty awful. But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. It's probably an array or somesuch. opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. Example: import std.conv; struct Foo { string num; uint numToString() { return to!uint(num); } alias numToString this; }
Jul 14 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 14, 2009 at 1:02 PM, dsimcha<dsimcha yahoo.com> wrote:
 =3D=3D Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s a=
rticle
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. =A0You might want to use such a type transparently in place of any other integer type, i.e. as an array index. =A0Something like "a[bi.toSizet()]" looks pretty awful. =A0But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. =A0It's probably an array or somesuch. =A0opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). =A0Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. =A0Example: import std.conv; struct Foo { =A0 string num; =A0 =A0uint numToString() { =A0 =A0 =A0 return to!uint(num); =A0 =A0} =A0 =A0alias numToString this; }
Oh, wow! :)
Jul 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Tue, Jul 14, 2009 at 1:02 PM, dsimcha<dsimcha yahoo.com> wrote:
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. You might want to use such a type transparently in place of any other integer type, i.e. as an array index. Something like "a[bi.toSizet()]" looks pretty awful. But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. It's probably an array or somesuch. opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. Example: import std.conv; struct Foo { string num; uint numToString() { return to!uint(num); } alias numToString this; }
Oh, wow! :)
Double-wow: you can alias to a function that returns a ref. Andrei
Jul 14 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 14, 2009 at 1:32 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Oh, wow! =A0:)
Double-wow: you can alias to a function that returns a ref.
My head just exploded.
Jul 14 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 10:02 AM, dsimcha<dsimcha yahoo.com> wrote:
 =3D=3D Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s a=
rticle
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. =A0You might want to use such a type transparently in place of any other integer type, i.e. as an array index. =A0Something like "a[bi.toSizet()]" looks pretty awful. =A0But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. =A0It's probably an array or somesuch. =A0opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). =A0Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. =A0Example: import std.conv; struct Foo { =A0 string num; =A0 =A0uint numToString() { =A0 =A0 =A0 return to!uint(num); =A0 =A0} =A0 =A0alias numToString this; }
That is cool. But numToString is a strange name for a function that turns a string into a uint. :-P --bb
Jul 14 2009
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
dsimcha Wrote:

 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. You might want to use such a type transparently in place of any other integer type, i.e. as an array index. Something like "a[bi.toSizet()]" looks pretty awful. But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. It's probably an array or somesuch. opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. Example: import std.conv; struct Foo { string num; uint numToString() { return to!uint(num); } alias numToString this; }
First of all I remember Walter saying that current limitation of one alias this per class/struct is temporary, it would be nice to hear a confirmation. Secondly, what about implicit cast in another way. I want some arbitrary type to be implicitly casted to my type. You can say that I can implement alias this for the former, but what if it is a primitive type. Can constructors be used for this? struct A { this(int) { .... } } // int now can be implicitly casted to A. Just a syntax sugar. Eldar
Jul 14 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Eldar Insafutdinov wrote:
 dsimcha Wrote:
 
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. You might want to use such a type transparently in place of any other integer type, i.e. as an array index. Something like "a[bi.toSizet()]" looks pretty awful. But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. It's probably an array or somesuch. opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. Example: import std.conv; struct Foo { string num; uint numToString() { return to!uint(num); } alias numToString this; }
First of all I remember Walter saying that current limitation of one alias this per class/struct is temporary, it would be nice to hear a confirmation. Secondly, what about implicit cast in another way. I want some arbitrary type to be implicitly casted to my type. You can say that I can implement alias this for the former, but what if it is a primitive type. Can constructors be used for this? struct A { this(int) { .... } } // int now can be implicitly casted to A. Just a syntax sugar. Eldar
I don't think it should be this simple. If I do this: class Vector { this (size_t length) { ... } } I don't want to be able to write this: Vector v = 3; Nor this: size_t length(Vector v) { ... } assert (length(3) == 3); I like the idea of being able to specify arbitrary implicit casts, but not the syntax. Rather, there should be an opImplicitCastFrom operator overload or something. -Lars
Jul 14 2009
next sibling parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Lars T. Kyllingstad Wrote:

 Eldar Insafutdinov wrote:
 dsimcha Wrote:
 
 == Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast
I think alias this should render that unnecesary.
'alias this' might cover a lot of cases, but this is the pretty big one that I can think of: consider a Bigint or the like. You might want to use such a type transparently in place of any other integer type, i.e. as an array index. Something like "a[bi.toSizet()]" looks pretty awful. But 'alias this' couldn't work in this case, because the underlying representation is *not* an integer. It's probably an array or somesuch. opImplicitCast would allow you to transparently use a Bigint in place of a normal int while still letting you represent the data any way you want (and letting you check the validity of the cast at runtime). Basically any type which represents its data as something other than what you want to implicitly cast to would have the same problem.
But you can alias this a function, not just a member. Example: import std.conv; struct Foo { string num; uint numToString() { return to!uint(num); } alias numToString this; }
First of all I remember Walter saying that current limitation of one alias this per class/struct is temporary, it would be nice to hear a confirmation. Secondly, what about implicit cast in another way. I want some arbitrary type to be implicitly casted to my type. You can say that I can implement alias this for the former, but what if it is a primitive type. Can constructors be used for this? struct A { this(int) { .... } } // int now can be implicitly casted to A. Just a syntax sugar. Eldar
I don't think it should be this simple. If I do this: class Vector { this (size_t length) { ... } } I don't want to be able to write this: Vector v = 3; Nor this: size_t length(Vector v) { ... } assert (length(3) == 3); I like the idea of being able to specify arbitrary implicit casts, but not the syntax. Rather, there should be an opImplicitCastFrom operator overload or something. -Lars
You are right, in that case opImplicitCastFrom would suffice. I suggested constructors solely for the purpose not to introduce new syntax. Though I doubt this will be implemented. Another thing is that it will create an ambiguity with opAssign.
Jul 14 2009
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-14 16:46:12 -0400, "Lars T. Kyllingstad" 
<public kyllingen.NOSPAMnet> said:

 I don't think it should be this simple. If I do this:
 
    class Vector
    {
        this (size_t length) { ... }
    }
 
 I don't want to be able to write this:
 
    Vector v = 3;
I agree. Constructors which can be used for implicit casting should be explicitly identified. Perhaps this way? class A { alias this(uint i) { ... } } -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 16 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 This is a great initiative. Let me add a few small points.
 [...]
Please you or someone else add those points to this page, so they don't get lost (I can't add them myself? It doesn't accept my name): http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2 You can also split that list in two parts, "core language" and "library". Another thing missing in that list is non-nullable classes/nullable: http://delight.sourceforge.net/null.html It's important for such list because it's a non backward-compatible change, this means you can't add that to the language and keep backward-compatibility too. If people what to add that, then it has to be done before D2 comes out of alpha state. (Otherwise if D3 will want to keep backward-compatibility to D2 then it will be not possible to be added again). I think it's an important enough thing. Bye, bearophile
Jul 14 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 Andrei Alexandrescu:
 This is a great initiative. Let me add a few small points.
 [...]
Please you or someone else add those points to this page, so they don't get lost (I can't add them myself? It doesn't accept my name): http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2 You can also split that list in two parts, "core language" and "library". Another thing missing in that list is non-nullable classes/nullable: http://delight.sourceforge.net/null.html It's important for such list because it's a non backward-compatible change, this means you can't add that to the language and keep backward-compatibility too. If people what to add that, then it has to be done before D2 comes out of alpha state. (Otherwise if D3 will want to keep backward-compatibility to D2 then it will be not possible to be added again). I think it's an important enough thing. Bye, bearophile
Can't nullable / non-nullable be done in library?
Jul 14 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Lutger:
Can't nullable / non-nullable be done in library?<
Yes, of course, people in the Scheme language have shown that you can do almost everything in library code. But to do that you need (beside fixing D library code, because the default now becomes non-null object references) a "pluggable type system", that is you must be able to plug-in a new piece of type system. You can do that with a meta (programmable) type-system like Haskell one, or with some kind of true plug-in (think about the "neutral" function/argument type annotations of Python3, that are a simple example of machinery that can be used to plug-in a library defined type system). I don't see both such things to be added to D2 anytime soon because they are complex, quite more complex than nonnullable object references. So I'm looking for just the ""small"" change in the type system plus the short leading "?" syntax. If D developers aren't interested in such thing, then a DEP can be written and then marked as officially refused, to avoid wasting future time discussing about this idea (this is another quite important purpose of Python PEPs, to mark ideas as refused and avoid discussing something hopeless over and over again). Bye, bearophile
Jul 14 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 Lutger:
Can't nullable / non-nullable be done in library?<
Yes, of course, people in the Scheme language have shown that you can do almost everything in library code. But to do that you need (beside fixing D library code, because the default now becomes non-null object references) a "pluggable type system", that is you must be able to plug-in a new piece of type system. You can do that with a meta (programmable) type-system like Haskell one, or with some kind of true plug-in (think about the "neutral" function/argument type annotations of Python3, that are a simple example of machinery that can be used to plug-in a library defined type system). I don't see both such things to be added to D2 anytime soon because they are complex, quite more complex than nonnullable object references. So I'm looking for just the ""small"" change in the type system plus the short leading "?" syntax. If D developers aren't interested in such thing, then a DEP can be written and then marked as officially refused, to avoid wasting future time discussing about this idea (this is another quite important purpose of Python PEPs, to mark ideas as refused and avoid discussing something hopeless over and over again). Bye, bearophile
Isn't .C#'s Nullable<T> a library thing? (It's quite useful for database crap) I mean, it's not as ambitious as non-nullable by default, but couldn't we develop a Nullable and NonNullable template with the tools we have today in D? (I'm not sure). Would that be good enough?
Jul 14 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Lutger:
 Isn't .C#'s Nullable<T> a library thing? (It's quite useful for database 
 crap)
C# nullable are nice because they have syntax support, so they are more handy than a purely library solution. But I was not talking about C# nullables :-) It's kind of the opposite, I was talking about non-nullable object references, have you read the link I have put in my answer to Andrei? http://delight.sourceforge.net/null.html Bye, bearophile
Jul 14 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lutger wrote:
 bearophile wrote:
 
 Andrei Alexandrescu:
 This is a great initiative. Let me add a few small points.
 [...]
Please you or someone else add those points to this page, so they don't get lost (I can't add them myself? It doesn't accept my name): http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2 You can also split that list in two parts, "core language" and "library". Another thing missing in that list is non-nullable classes/nullable: http://delight.sourceforge.net/null.html It's important for such list because it's a non backward-compatible change, this means you can't add that to the language and keep backward-compatibility too. If people what to add that, then it has to be done before D2 comes out of alpha state. (Otherwise if D3 will want to keep backward-compatibility to D2 then it will be not possible to be added again). I think it's an important enough thing. Bye, bearophile
Can't nullable / non-nullable be done in library?
It could if there was a way to disable the default constructor. Walter seemed to be interested in the idea. Andrei
Jul 14 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 It could if there was a way to disable the default constructor. Walter 
 seemed to be interested in the idea.
(I'm always a little suspicious of library solutions, because they sometimes smell of over-generalization, but sometimes they are a better solution.) It's interesting, can you please quickly show me how disabling the default constructor may allow you to implement this solution? Bye, bearophile
Jul 15 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
bearophile wrote:
 Andrei Alexandrescu:
 It could if there was a way to disable the default constructor. Walter 
 seemed to be interested in the idea.
(I'm always a little suspicious of library solutions, because they sometimes smell of over-generalization, but sometimes they are a better solution.) It's interesting, can you please quickly show me how disabling the default constructor may allow you to implement this solution?
Because:
 struct NonNullable(T)
 {
   T ptr;
   alias ptr this;

   this(T ptr)
   {
     assert(ptr !is null);
     this.ptr = ptr;
   }
   this(NonNullable!T ptr)
   {
     this.ptr = ptr.ptr;
   }
 }

 // Boom!  I just broke your non-nullable type!
 NonNullable!Object o;
Jul 15 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Keep:
 Because:
 
 struct NonNullable(T)
 {
   T ptr;
   alias ptr this;

   this(T ptr)
   {
     assert(ptr !is null);
     this.ptr = ptr;
   }
   this(NonNullable!T ptr)
   {
     this.ptr = ptr.ptr;
   }
 }

 // Boom!  I just broke your non-nullable type!
 NonNullable!Object o;
I am sorry, but I don't understand still. That's valid D2 code, and I can understand it. But from its look it seems (beside the not handy syntax, it's not as adding a "?") the opposite of what I was saying (that by default all D objects have to be non-nullable). Can you please help me understand? :-) Bye, bearophile
Jul 15 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Jul 15, 2009 at 5:37 PM, bearophile<bearophileHUGS lycos.com> wrote=
:
 Daniel Keep:
 Because:

 struct NonNullable(T)
 {
 =A0 T ptr;
 =A0 alias ptr this;

 =A0 this(T ptr)
 =A0 {
 =A0 =A0 assert(ptr !is null);
 =A0 =A0 this.ptr =3D ptr;
 =A0 }
 =A0 this(NonNullable!T ptr)
 =A0 {
 =A0 =A0 this.ptr =3D ptr.ptr;
 =A0 }
 }

 // Boom! =A0I just broke your non-nullable type!
 NonNullable!Object o;
I am sorry, but I don't understand still. That's valid D2 code, and I can=
understand it. But from its look it seems (beside the not handy syntax, it= 's not as adding a "?") the opposite of what I was saying (that by default = all D objects have to be non-nullable). Can you please help me understand? = :-) If you declare: NonNullable! Object o; o.ptr is initialized to null, because you aren't required to call its constructor. If you were able to disable the default constructor, this line would give you an error, and you would be required to write: NonNullable! Object o =3D new Object(); or so.
Jul 15 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jul 15, 2009 at 2:42 PM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:
 On Wed, Jul 15, 2009 at 5:37 PM, bearophile<bearophileHUGS lycos.com> wro=
te:
 Daniel Keep:
 Because:

 struct NonNullable(T)
 {
 =A0 T ptr;
 =A0 alias ptr this;

 =A0 this(T ptr)
 =A0 {
 =A0 =A0 assert(ptr !is null);
 =A0 =A0 this.ptr =3D ptr;
 =A0 }
 =A0 this(NonNullable!T ptr)
 =A0 {
 =A0 =A0 this.ptr =3D ptr.ptr;
 =A0 }
 }

 // Boom! =A0I just broke your non-nullable type!
 NonNullable!Object o;
I am sorry, but I don't understand still. That's valid D2 code, and I ca=
n understand it. But from its look it seems (beside the not handy syntax, i= t's not as adding a "?") the opposite of what I was saying (that by default= all D objects have to be non-nullable). Can you please help me understand?= :-)
 If you declare:

 NonNullable! Object o;

 o.ptr is initialized to null, because you aren't required to call its
 constructor. =A0If you were able to disable the default constructor,
 this line would give you an error, and you would be required to write:

 NonNullable! Object o =3D new Object();

 or so.
Maybe it would be less confusing to say "disable the default initializer". --bb
Jul 15 2009
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 14 Jul 2009 12:42:56 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 Don wrote:
 - Operator overloading. "completely redone" (?)
I think they should be redone. There are several issues: 1. Currently there's no provision for "expr1[expr2] = expr3", where is some binary operator. The opIndexAssign is more like the token presence that makes the absence felt even better. Scaling to opIndexAddAssign etc. seems to be overkill. 2. Operators = are dubious for classes because a class can't define "a = b" to mean the same as "a = a b". (I recall you were the first to note that.) I'd venture to think that many arithmetic operators don't make much sense for classes to start with. 3. There are types for which ++ or -- make sense but addition does not (e.g. STL-style iterators). 4. opXxx_r and opXxx can easily be ambiguous, as you noted in a recent thread. (I think that could be fixed with other means though.) 5. Defining operators asks for code duplication. Usually people want to define all arithmetic operators to forward to some member. That is unnecessarily verbose (see e.g. the implementation of std.variant which makes heroic efforts to counter that). Any other issues? (I feel I forgot a couple.) Maybe we can fix all of these by patching the existing system.
I slicing and indexing need to be unified, as its common with multi-dimensional data to slice one dimension and index another. Consider slicing the first row of a matrix: auto row0 = m[0,0..$]; (Also a multi-dimensional opDollar ->i.e. opDollar(size_t D){}, is needed)
Jul 14 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Robert Jacques:
 I slicing and indexing need to be unified, as its common with  
 multi-dimensional data to slice one dimension and index another. Consider  
 slicing the first row of a matrix:
 auto row0 = m[0,0..$];
 (Also a multi-dimensional opDollar ->i.e. opDollar(size_t D){}, is needed)
I agree. I don't know if that's the best idea, but something OK. Please add it to: http://www.wikiservice.at/d/wiki.cgi?LanguageDevel#section2 (I have seen someone has updated that page in the meantime. I suggest to put there especially the things that break backward compatibility, because the other things can eventually be added to D3). Bye, bearophile
Jul 15 2009
prev sibling next sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Don's list is:

 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
I think that a list like this is a very positive step, particularly given its source - thanks Don. However, I think that it should be split in two so that there is a compiler list, and a library list. It seems quite reasonable for the library to lag the compiler. Possibly at the top of the compiler list should be the question of a formal definition of D2. Appropriate compiler support for multithreading seems like a must. The operator overloading issue should be judged by the simple question "does this change make D into E". At the top of the library list should be an arbitrary resolution of the ongoing Phobos/Tango hiatus. I have no idea who can make such an arbitrary decision, since the inner processes of D decision making are opaque. As I've suggested before, Phobos could simply be renamed as the 'D Standard Library'. That should do the trick. Steve
Jul 14 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Clipsham:
What exactly is it you mean by this?<
I keep saying wrong things every day, so this too can be wrong. DMD back-end is not bad, it compiles quite quickly, and there are many tests where the binary it produces is a bit faster than the binary produced by LDC. But LLVM offers many interesting things that are hard to do with DMD's back-end, often such things are already implemented in LLVM (maybe not fully refined yet, but they are working on it) and they are waiting to be used. I'm looking at the linker too, for example with LDC you can do advanced Link-time optimizations, and in future it will probably be able to do even more things (like reducing code bloat produced by templates). On the other hand few things done by DMD are hard to do with LLVM. So I think D development/developers have to take a more serious look at LLVM, and to design D2 thinking that LLVM and its qualities may be available. A language like D must not be designed to work on LLVM only; but ignoring what LLVM offers, and limiting the D design just to what is able to do today the DMD backend, is not right. If D will become widespread, four years from now people will probably use LDC more than DMD, so designing D around the limits of DMD doesn't sound right. In another post I have listed part of the things offered by LLVM, for example it can compile pieces of code dynamically at runtime, and the compiler can be used as a collection of tools to compile code, etc. Such feature was refused by Walter also because it's hard/long to implement (on DMD). But if it's available then it may be better to think what can be done with LLVM. Bye, bearophile
Jul 14 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 14, 2009 at 1:37 PM, bearophile<bearophileHUGS lycos.com> wrote=
:
 Robert Clipsham:
 But LLVM offers many interesting things that are hard to do with DMD's ba=
ck-end, often such things are already implemented in LLVM (maybe not fully = refined yet, but they are working on it) and they are waiting to be used. I= 'm looking at the linker too, for example with LDC you can do advanced Link= -time optimizations, and in future it will probably be able to do even more= things (like reducing code bloat produced by templates).
 On the other hand few things done by DMD are hard to do with LLVM.
Except for generating exceptions on Windows, apparently. I agree with you generally though. --bb
Jul 14 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 14 de julio a las 16:37 me escribiste:
 Robert Clipsham:
What exactly is it you mean by this?<
I keep saying wrong things every day, so this too can be wrong. DMD back-end is not bad, it compiles quite quickly, and there are many tests where the binary it produces is a bit faster than the binary produced by LDC. But LLVM offers many interesting things that are hard to do with DMD's back-end, often such things are already implemented in LLVM (maybe not fully refined yet, but they are working on it) and they are waiting to be used. I'm looking at the linker too, for example with LDC you can do advanced Link-time optimizations, and in future it will probably be able to do even more things (like reducing code bloat produced by templates). On the other hand few things done by DMD are hard to do with LLVM. So I think D development/developers have to take a more serious look at LLVM, and to design D2 thinking that LLVM and its qualities may be available. A language like D must not be designed to work on LLVM only; but ignoring what LLVM offers, and limiting the D design just to what is able to do today the DMD backend, is not right. If D will become widespread, four years from now people will probably use LDC more than DMD, so designing D around the limits of DMD doesn't sound right. In another post I have listed part of the things offered by LLVM, for example it can compile pieces of code dynamically at runtime, and the compiler can be used as a collection of tools to compile code, etc. Such feature was refused by Walter also because it's hard/long to implement (on DMD). But if it's available then it may be better to think what can be done with LLVM.
And most of that list where just optimizations, that nothing had to do with the language. I think you have no point on this one (even when I do strongly believe that LDC can be a much better compiler than DMD and LLVM is a great backend). And even for things that are relevant to the language, I don't think D should be attached to *any* backend, not DMD, not LLVM. Things required by the specification should be doable in any backend if you plan to see more compilers in the future. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Los jóvenes no son solo brazos que nos cargan... También se los puede mandar a la guerra, que es su obligación. -- Ricardo Vaporeso
Jul 14 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:
 And even for things that are relevant to the language, I don't think
 D should be attached to *any* backend, not DMD, not LLVM. Things required
 by the specification should be doable in any backend if you plan to see
 more compilers in the future.
I agree that restricting D to just the single LLVM is bad, but doing the opposite too is bad: if you look just for the greatest common divisor among back-ends then you probably have to remove from the D specs the "real" type, because I think GCC can't implement them well. So some compromise have to be found. And generally having a good open-source reference implementation of a language is better than having three weak implementations (some dynamic languages survive fine for years with just one reference implementation, and they often don't even have formal specs). Bye, bearophile
Jul 14 2009
prev sibling next sibling parent reply Christian Kamm <check ldc-commits.com> writes:
bearophile Wrote:
 - making D2 fitter for the LLVM back-end;
I do not think this is necessary. LDC can implement most of D1 just fine on top of LLVM. The omissions are minor: http://www.dsource.org/projects/ldc/wiki/Docs#Violationsofthespecification Exposing particular features of the backend to the user should be done through compiler-specific extensions. See http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions for an example. Otherwise you'll make implementing a correct backend for D even harder.
Jul 15 2009
parent reply Don <nospam nospam.com> writes:
Christian Kamm wrote:
 bearophile Wrote:
 - making D2 fitter for the LLVM back-end;
I do not think this is necessary. LDC can implement most of D1 just fine on top of LLVM. The omissions are minor: http://www.dsource.org/projects/ldc/wiki/Docs#Violationsofthespecification Exposing particular features of the backend to the user should be done through compiler-specific extensions. See http://www.dsource.org/projects/ldc/wiki/InlineAsmExpressions for an example. Otherwise you'll make implementing a correct backend for D even harder.
It's the other way around. We need to remove the places where DMD's backend is exposed in the language. It's reassuring that LDC has been made without finding many such cases.
Jul 15 2009
parent Christian Kamm <check ldc-commits.com> writes:
Don Wrote:
 It's the other way around. We need to remove the places where DMD's 
 backend is exposed in the language. It's reassuring that LDC has been 
 made without finding many such cases.
I agree. From my point of view naked functions and inline assembly - and the associated assumption that we have direct control over the emitted assembly - have caused the most issues. It seems to be appropriate for D though. There's also the D calling convention; we've pretty much got it covered now, but there's a reason GDC still uses the C one instead. Finally, some of the semantic checking in DMD is done in the backend instead of the frontend. These have always caused trouble until we patched the frontend or inserted similar checking into our own backend code. Unfortunately we haven't kept a list of these around (or opened tickets for them).
Jul 15 2009
prev sibling parent Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Tue, Jul 14, 2009 at 11:12 PM, Bill Baxter<wbaxter gmail.com> wrote:
 On Tue, Jul 14, 2009 at 1:37 PM, bearophile<bearophileHUGS lycos.com> wro=
te:
 Robert Clipsham:
 But LLVM offers many interesting things that are hard to do with DMD's b=
ack-end, often such things are already implemented in LLVM (maybe not fully= refined yet, but they are working on it) and they are waiting to be used. = I'm looking at the linker too, for example with LDC you can do advanced Lin= k-time optimizations, and in future it will probably be able to do even mor= e things (like reducing code bloat produced by templates).
 On the other hand few things done by DMD are hard to do with LLVM.
Except for generating exceptions on Windows, apparently.
LLVM is getting better support for SJLJ exception handling. This would get us to the same point GCC is at. I think the bigger problem is lack of documentation on SEH and the runtime support Windows provides for it. There has even been some mailing list threads about it on LLVMDev recently... I think the best solution will be to use Dwarf on Windows eventually as well (which also seems to be the route GCC is going). I'm not sure how Walter figured these things out ?
 I agree with you generally though.

 --bb
Jul 15 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Other, less technical items:
 A clear and "finalized" spec. If it isn't implemented, it should be yanked
(or clearly marked as pending)
 A plan for library support. Not just Tango, but also Phobos. D1 Phobos could
not evolve.

Don Wrote:

 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
 
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
Jul 14 2009
parent reply Benji Smith <dlanguage benjismith.net> writes:
Jason House wrote:
 Other, less technical items:
  A clear and "finalized" spec. If it isn't implemented, it should be yanked
(or clearly marked as pending)
  A plan for library support. Not just Tango, but also Phobos. D1 Phobos could
not evolve.
In D1, I enthusiastically used Tango. I haven't used D2 yet (because all my code is heavily tied to the Tango libs), but I suspect that when D2 is finalized, I'll port everything over to Phobos. I've read all the Phobos2 development discussions here (most notably the range discussions), but what about the feature disparities between the two libraries. What types of functionality are currently present in Tango but absent in Phobos? Maybe if Andrei put together a list of missing Phobos functionality, we could get people from the community to flesh out the libs. For example, I have a JSON parser implementation that I'd be happy to contribute. --benji
Jul 22 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Jason House wrote:
 Other, less technical items:
  A clear and "finalized" spec. If it isn't implemented, it should be 
 yanked (or clearly marked as pending)
  A plan for library support. Not just Tango, but also Phobos. D1 
 Phobos could not evolve.
In D1, I enthusiastically used Tango. I haven't used D2 yet (because all my code is heavily tied to the Tango libs), but I suspect that when D2 is finalized, I'll port everything over to Phobos. I've read all the Phobos2 development discussions here (most notably the range discussions), but what about the feature disparities between the two libraries. What types of functionality are currently present in Tango but absent in Phobos? Maybe if Andrei put together a list of missing Phobos functionality, we could get people from the community to flesh out the libs.
I think we'd need at a minimum: * better networking library * containers * just a little linear algebra basics (i.e. well-defined storage that would allow us to interface with high-performance libraries) * at least some essentials for compile-time introspection (Shin, I'm still working on integrating WhiteHole and BlackHole; I want to expand your support function into a better fleshed and more general functionality) * a few functions here and there, e.g. readf * a complete rewrite of std.xml which is currently so slow it's not even funny * of course last but not least concurrency support * some more generic types a la std.typecons * flesh out std.complex which is to supplant the dying complex built-in type
 For example, I have a JSON parser implementation that I'd be happy to 
 contribute.
That would be great. In general, it would be awesome to gather more contributions from the community. There's a thirst to contribute and we'll be glad to involve this group into some serious design e.g. for concurrency support, as well as accept code for functionality that belongs to the standard library. In the bulleted list above there are many mini-projects that are confined enough to be done by one willing individual in a relatively short time. Andrei
Jul 22 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 22 Jul 2009 21:55:54 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 I think we'd need at a minimum:
what are your opinions on the I/O subsystem? I think a lot of performance/features could be gained by using D-based buffered I/O instead of the C standard lib. Tango is pretty much a testament to that... -Steve
Jul 22 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Wed, 22 Jul 2009 21:55:54 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 I think we'd need at a minimum:
what are your opinions on the I/O subsystem? I think a lot of performance/features could be gained by using D-based buffered I/O instead of the C standard lib. Tango is pretty much a testament to that...
Better speed is always nice, so it would be great to see some work in that direction. What are the specific shortcomings that make using stdio unrecommended? Andrei
Jul 22 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 22 Jul 2009 22:03:56 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Wed, 22 Jul 2009 21:55:54 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 I think we'd need at a minimum:
what are your opinions on the I/O subsystem? I think a lot of performance/features could be gained by using D-based buffered I/O instead of the C standard lib. Tango is pretty much a testament to that...
Better speed is always nice, so it would be great to see some work in that direction. What are the specific shortcomings that make using stdio unrecommended?
For one, you are not limited to the standard C libraries buffering features, there are a lot of cool things you can do with buffers in D that just weren't imagined or possible back when the API for C's stdio was developed. Take a look at the docs for Tango's buffering system (http://www.dsource.org/projects/tango/docs/stable/ look at tango.io.stream.Buffered and tango.io.device.Array). It's also one less abstraction layer to go through. -Steve
Jul 22 2009
prev sibling next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 22 Jul 2009 20:55:54 -0500, Andrei Alexandrescu wrote:

 I think we'd need at a minimum:
 
 * better networking library
 
 * containers
 
 * just a little linear algebra basics (i.e. well-defined storage that
 would allow us to interface with high-performance libraries)
 
 * at least some essentials for compile-time introspection (Shin, I'm
 still working on integrating WhiteHole and BlackHole; I want to expand
 your support function into a better fleshed and more general
 functionality)
 
 * a few functions here and there, e.g. readf
 
 * a complete rewrite of std.xml which is currently so slow it's not even
 funny
 
 * of course last but not least concurrency support
 
 * some more generic types a la std.typecons
 
 * flesh out std.complex which is to supplant the dying complex built-in
 type
 
 
 Andrei
These points were added to: http://www.prowiki.org/wiki4d/wiki.cgi?PhobosToDo Where they shall sit a long horrible life :P
Jul 22 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jesse Phillips wrote:
 On Wed, 22 Jul 2009 20:55:54 -0500, Andrei Alexandrescu wrote:
 
 I think we'd need at a minimum:

 * better networking library

 * containers

 * just a little linear algebra basics (i.e. well-defined storage that
 would allow us to interface with high-performance libraries)

 * at least some essentials for compile-time introspection (Shin, I'm
 still working on integrating WhiteHole and BlackHole; I want to expand
 your support function into a better fleshed and more general
 functionality)

 * a few functions here and there, e.g. readf

 * a complete rewrite of std.xml which is currently so slow it's not even
 funny

 * of course last but not least concurrency support

 * some more generic types a la std.typecons

 * flesh out std.complex which is to supplant the dying complex built-in
 type


 Andrei
These points were added to: http://www.prowiki.org/wiki4d/wiki.cgi?PhobosToDo Where they shall sit a long horrible life :P
I suggest anyone who wants to do something for D to focus on the installation aspect. It's a relatively well-defined project of high importance and high visibility. We simply can't afford to introduce D to the world without a state-of-the-art installation procedure. Andrei
Jul 22 2009
next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Andrei Alexandrescu wrote:
 I suggest anyone who wants to do something for D to focus on the 
 installation aspect. It's a relatively well-defined project of high 
 importance and high visibility. We simply can't afford to introduce D to 
 the world without a state-of-the-art installation procedure.
I made some installers for the DMD 1.00 introduction, but back then the .zip (or the missing .tgz) were still the preferred procedure... http://www.algonet.se/~afb/d/dmd-setup.html for Windows http://www.algonet.se/~afb/d/rpm-setup.html for Linux So the installers were only used for the portable D compiler (gdc) in the complementary gdcwin/gdcgnu/gcmac projects. The dgcc upstream always used .tar.bz2, similar to how dmd used .zip for the releases. But with proper documentation, it wasn't *that* much extra hassle... Going through the installation wizards is more "familiar", but probably not less work than going through the install steps with unzip, cp, chmod and $PATH and whatnot, with the contributions at: http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler I like having installers myself, but it seemed like install problems were mostly given as "yet another excuse" to not try the D language. Even with the dmd/gdc installers, you'd get the "where's the IDE" or "where's the GUI" so it's mostly about documentation and presentation ? I won't do any dmd2/ldc installers myself I think, but will keep the dmd1/gdc installers up for as long as there seems to be interest... Should probably update the SF web pages with the new information on the development of D, since currently they all date back to 2008. --anders
Jul 23 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 I suggest anyone who wants to do something for D to focus on the 
 installation aspect. It's a relatively well-defined project of high 
 importance and high visibility. We simply can't afford to introduce D to 
 the world without a state-of-the-art installation procedure.
 
 
 Andrei
Not everyone is capable of effeciently helping in that area. Will there ever be an official list of things like this? Searching the mailing list is not an effective way of finding what you/Walter consider to be valuable additions. A list allows a motivated contributor to quickly find something that interests them. Having only one item also makes people think that somebody else is probably doing it and they don't need to help.
Jul 23 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 I suggest anyone who wants to do something for D to focus on the 
 installation aspect. It's a relatively well-defined project of high 
 importance and high visibility. We simply can't afford to introduce D to 
 the world without a state-of-the-art installation procedure.


 Andrei
Not everyone is capable of effeciently helping in that area. Will there ever be an official list of things like this? Searching the mailing list is not an effective way of finding what you/Walter consider to be valuable additions. A list allows a motivated contributor to quickly find something that interests them. Having only one item also makes people think that somebody else is probably doing it and they don't need to help.
You may want to bookmark http://www.prowiki.org/wiki4d/wiki.cgi?PhobosToDo Andrei
Jul 23 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Maybe if Andrei put together a list of 
 missing Phobos functionality, we could get people from the community 
 to flesh out the libs.
I think we'd need at a minimum:
<snip>
 That would be great. In general, it would be awesome to gather more 
 contributions from the community. There's a thirst to contribute and 
 we'll be glad to involve this group into some serious design e.g. for 
 concurrency support, as well as accept code for functionality that 
 belongs to the standard library.
 
 In the bulleted list above there are many mini-projects that are 
 confined enough to be done by one willing individual in a relatively 
 short time.
Are there contributor guidelines somewhere? For example, should the author of a container library prefer classes or structs? Should other (non-container) modules accept container classes as arguments? Or only container interfaces (if there are any such things) or just ranges? Is it appropriate to use an empty struct purely as a namespace for the introduction of free functions? Or should free functions be placed at the module level? Is it appropriate to define multiple classes, structs, templates, etc within a single module? What considerations should inform the decision regarding the placement of module boundaries? What constitutes appropriate/inappropriate usage of opCall? Anyhoo... Point being, Phobos_1 was a hodgepodge of different conventions and styles. Tango_1 was considerably better, in terms of stylistic uniformity. But it used a very different set of idioms than Phobos_1 (lots of predicate functions, "sink" delegates, etc). Probably any author contributing code to Phobos_2 should spend a little time getting up to speed with the preferred idioms before writing code. I suspect that my humble little JSON parser uses styles and idioms that would clash with the majority of Phobos_2 (since my programming pedigree comes from Java, C#, JavaScript, and Perl much moreso than C or C++). --benji
Jul 26 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-26 23:36:06 -0400, Benji Smith <dlanguage benjismith.net> said:

 Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Maybe if Andrei put together a list of
 missing Phobos functionality, we could get people from the community to 
 flesh out the libs.
I think we'd need at a minimum:
<snip>
 That would be great. In general, it would be awesome to gather more 
 contributions from the community. There's a thirst to contribute and 
 we'll be glad to involve this group into some serious design e.g. for 
 concurrency support, as well as accept code for functionality that 
 belongs to the standard library.
 
 In the bulleted list above there are many mini-projects that are 
 confined enough to be done by one willing individual in a relatively 
 short time.
Are there contributor guidelines somewhere?
Funny. I started to write some guidelines a few months ago. Those were guidelines about how to name things consistently: like types should be camel-cased nouns possibly prefixed with adjectives starting with an uppercase; variables, getters, and setters should be camel-cased nouns starting with a lowercase; functions that perform an action should contain with a verb, short names should be avoided if they aren't meaningful, etc. Then I found that most of Phobos would have to change to fit my guidelines, and I couldn't come with anything sensible that would fit half of Phobos, so I gave up. If someone's insterested, I can post them somewhere. Unfortunatly, I wonder if this lack of guidelines is slowing contributions to Phobos, with everyone who aims at good integration wasting their time trying to figure out the rules. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 27 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 Benji Smith wrote:
 Maybe if Andrei put together a list of
 missing Phobos functionality, we could get people from the community 
 to flesh out the libs.
I think we'd need at a minimum:
<snip>
 That would be great. In general, it would be awesome to gather more 
 contributions from the community. There's a thirst to contribute and 
 we'll be glad to involve this group into some serious design e.g. for 
 concurrency support, as well as accept code for functionality that 
 belongs to the standard library.

 In the bulleted list above there are many mini-projects that are 
 confined enough to be done by one willing individual in a relatively 
 short time.
Are there contributor guidelines somewhere?
Not at the moment.
 For example, should the author of a container library prefer classes or 
 structs?
I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".
 Should other (non-container) modules accept container classes 
 as arguments? Or only container interfaces (if there are any such 
 things) or just ranges?
I think ranges should be preferred wherever applicable.
 Is it appropriate to use an empty struct purely as a namespace for the 
 introduction of free functions? Or should free functions be placed at 
 the module level?
I think module-level functions are best. If there are lookup issues due to that, we need to fix the language. D is conceived to allow proper coexistence of functions in different modules without forcing the user to take too many precautions.
 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
 What constitutes appropriate/inappropriate usage of opCall?
What examples do you have in mind?
 Anyhoo...
 
 Point being, Phobos_1 was a hodgepodge of different conventions and 
 styles. Tango_1 was considerably better, in terms of stylistic 
 uniformity. But it used a very different set of idioms than Phobos_1 
 (lots of predicate functions, "sink" delegates, etc). Probably any 
 author contributing code to Phobos_2 should spend a little time getting 
 up to speed with the preferred idioms before writing code.
I agree. I am obviously subjective, but here are a few modules in phobos2 that seem to me close to the desired look and feel: * std.algorithm is a large collection of functions mostly operating on one abstraction (ranges). If you know how to use one algorithm, you probably know how to use all others. Defining ranges that std.algorithm can work with is also a breeze. * std.getopt is a very effective module. Although it does a fair amount of stuff, it has a simple interface that can be learned in minutes. I haven't seen an options parsing library that has the same power/ease ratio. Its usage of static types to infer what you want to do is a good showcase for the power of D templates and variadics. * std.conv is simple (in interface), convenient, and general. * std.range could use some maturing. I'm currently not 100% pleased about it. * std.file looks a bit quaint (e.g. no classes) but I'm comfortable around it. It does what it's supposed to do and does it well. * std.numeric is an example of a library that has a mix of functions and objects collected under an umbrella topic. I'm ok with it, but at some point I suspect I'd start worrying about its growth. Same about e.g. std.typecons. * std.md5 is an example on why it's not that advisable to just copy a C interface into D. (This is a negative example.) * std.random is a simple, extensible design, and has convenience functions (such as uniform) that are, well, darn convenient. I see it growing easily and nicely.
 I suspect that my humble little JSON parser uses styles and idioms that 
 would clash with the majority of Phobos_2 (since my programming pedigree 
 comes from Java, C#, JavaScript, and Perl much moreso than C or C++).
Phobos2 doesn't have (m)any hierarchies not because Walter or I don't use them or like them. It's just that the particular stuff that's in Phobos right now is at an advantage by using other design means. But if you come with a good hierarchy implementing a piece of functionality, great. Andrei
Jul 27 2009
next sibling parent reply yigal chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu Wrote:

 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. Andrei
The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with. yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong. -- Yigal
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
yigal chripun wrote:
 Andrei Alexandrescu Wrote:
 
 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. Andrei
The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with. yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong.
I think public import can help with that. Andrei
Jul 27 2009
parent reply yigal chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu Wrote:

 yigal chripun wrote:
 Andrei Alexandrescu Wrote:
 
 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. Andrei
The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with. yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong.
I think public import can help with that. Andrei
That is just a work-around and not a full solution. this is a weak spot in D which I'd like to see fixed. I've already suggested in the past some ideas on how this can be solved. we need a reasonable tradeoff between the namespaces design of C# which is completely seperated from physical layout (filesystem) and the packages design of Java which is tightly coupled with the filesystem.
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
yigal chripun wrote:
 Andrei Alexandrescu Wrote:
 
 yigal chripun wrote:
 Andrei Alexandrescu Wrote:
 
 Is it appropriate to define multiple classes, structs,
 templates, etc within a single module? What considerations
 should inform the decision regarding the placement of module
 boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. Andrei
The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with. yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong.
I think public import can help with that. Andrei
That is just a work-around and not a full solution.
Why?
 this is a weak
 spot in D which I'd like to see fixed.
Why is it a weak spot? What problems mar its advantages? Andrei
Jul 27 2009
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Andrei Alexandrescu wrote:
 yigal chripun wrote:
 Andrei Alexandrescu Wrote:

 yigal chripun wrote:
 Andrei Alexandrescu Wrote:

 Is it appropriate to define multiple classes, structs,
 templates, etc within a single module? What considerations
 should inform the decision regarding the placement of module
 boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails. Andrei
The rule of thumb above is good in theory but in practice such a given bundle of functionality can produce a 30_000 line file. while all those lines should be "bundled" conceptually together, D's restriction of module == file makes for a huge file that is a hassle to work with. yes, a "module" should represent a conceptual bundle of functionallity but forcing this into one huge file is wrong.
I think public import can help with that. Andrei
That is just a work-around and not a full solution.
Why?
 this is a weak
 spot in D which I'd like to see fixed.
Why is it a weak spot? What problems mar its advantages?
I think the approach with public imports should work in principle (although would probably require making a package for such 'module bundles' to have package-level field visibility, since private members would not be accessible across modules), but currently the DMD frontend fails at circular dependencies making this approach impossible. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jul 27 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
For example, should the author of a container library prefer classes or 
structs?
I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".
About values vs. reference semantics, I think reference is the best. Containers usually are big, and you don't want to copy them arround. I find myself using lots of references to pass containers arround in C++ and almost never use the copy() method of Python containers, so based on *my* experience, I'd say that reference as the default is the best approach. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Seducimos a una minita con el objetivo de llevarla a nuestro hogar; más que seducirla la amenazamos con una botella. -- Sidharta Kiwi
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
 For example, should the author of a container library prefer classes or 
 structs?
I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".
About values vs. reference semantics, I think reference is the best. Containers usually are big, and you don't want to copy them arround. I find myself using lots of references to pass containers arround in C++ and almost never use the copy() method of Python containers, so based on *my* experience, I'd say that reference as the default is the best approach.
Sounds convincing. Andrei
Jul 27 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 7:48 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
 For example, should the author of a container library prefer classes or
 structs?
I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".
About values vs. reference semantics, I think reference is the best. Containers usually are big, and you don't want to copy them arround. I find myself using lots of references to pass containers arround in C++ and almost never use the copy() method of Python containers, so based on *my* experience, I'd say that reference as the default is the best approach.
Sounds convincing.
That's exactly right except for the times when it isn't and what you want is value semantics. I've just finished recently refactoring some C++ code that wasn't designed with copying in mind. Changing all the "float* data; int data_length;" members into std::vectors did the trick. The data they contained wasn't particularly large, and there was no real need to introduce the complexity that sharing it between copied instances would have created. --bb
Jul 27 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 9:54 AM, Bill Baxter<wbaxter gmail.com> wrote:
 On Mon, Jul 27, 2009 at 7:48 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
 For example, should the author of a container library prefer classes =
or
 structs?
I've been struggling with this forever. I don't know. I don't even kno=
w
 whether reference or value semantics are best for containers. I don't
 know whether abstract container interfaces and container-independent
 code are a net win; experience with STL seems to say "don't" and
 experience with Java seems to say "ho-hum".
About values vs. reference semantics, I think reference is the best. Containers usually are big, and you don't want to copy them arround. I find myself using lots of references to pass containers arround in C+=
+
 and almost never use the copy() method of Python containers, so based o=
n
 *my* experience, I'd say that reference as the default is the best
 approach.
Sounds convincing.
That's exactly right except for the times when it isn't and what you want is value semantics. I've just finished recently refactoring some C++ code that wasn't designed with copying in mind. =A0Changing all the "float* data; int data_length;" members into std::vectors did the trick. =A0The data they contained wasn't particularly large, and there was no real need to introduce the complexity that sharing it between copied instances would have created.
So if I didn't make it clear -- my opinion is that whether containers should be by value or by ref depends on the circumstances and that choice should be left to the programmer. Thus the question becomes what's the easiest way to provide both? Three options I see: 1) Write ref classes and wrap them in structs 2) Write value structs and wrap them in classes 3) Write template mixins and mix them into both struct and class shells. I think given the existence of "alias this" for structs, 1 is actually the best-supported paradigm. I think with that you should be able to value-ize a by-ref container class just by writing a post-blitter to copy the contents. --bb
Jul 27 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Mon, Jul 27, 2009 at 9:54 AM, Bill Baxter<wbaxter gmail.com> wrote:
 On Mon, Jul 27, 2009 at 7:48 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
 For example, should the author of a container library prefer classes or
 structs?
I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".
About values vs. reference semantics, I think reference is the best. Containers usually are big, and you don't want to copy them arround. I find myself using lots of references to pass containers arround in C++ and almost never use the copy() method of Python containers, so based on *my* experience, I'd say that reference as the default is the best approach.
Sounds convincing.
That's exactly right except for the times when it isn't and what you want is value semantics. I've just finished recently refactoring some C++ code that wasn't designed with copying in mind. Changing all the "float* data; int data_length;" members into std::vectors did the trick. The data they contained wasn't particularly large, and there was no real need to introduce the complexity that sharing it between copied instances would have created.
So if I didn't make it clear -- my opinion is that whether containers should be by value or by ref depends on the circumstances and that choice should be left to the programmer. Thus the question becomes what's the easiest way to provide both? Three options I see: 1) Write ref classes and wrap them in structs 2) Write value structs and wrap them in classes 3) Write template mixins and mix them into both struct and class shells. I think given the existence of "alias this" for structs, 1 is actually the best-supported paradigm. I think with that you should be able to value-ize a by-ref container class just by writing a post-blitter to copy the contents. --bb
These thoughts are very much aligned with mine. Thanks Bill. Andrei
Jul 27 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 10:01 AM, Bill Baxter<wbaxter gmail.com> wrote:
 On Mon, Jul 27, 2009 at 9:54 AM, Bill Baxter<wbaxter gmail.com> wrote:
 On Mon, Jul 27, 2009 at 7:48 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 07:59 me escribiste:
 For example, should the author of a container library prefer classes=
or
 structs?
I've been struggling with this forever. I don't know. I don't even kn=
ow
 whether reference or value semantics are best for containers. I don't
 know whether abstract container interfaces and container-independent
 code are a net win; experience with STL seems to say "don't" and
 experience with Java seems to say "ho-hum".
About values vs. reference semantics, I think reference is the best. Containers usually are big, and you don't want to copy them arround. I find myself using lots of references to pass containers arround in C=
++
 and almost never use the copy() method of Python containers, so based =
on
 *my* experience, I'd say that reference as the default is the best
 approach.
Sounds convincing.
That's exactly right except for the times when it isn't and what you want is value semantics. I've just finished recently refactoring some C++ code that wasn't designed with copying in mind. =A0Changing all the "float* data; int data_length;" members into std::vectors did the trick. =A0The data they contained wasn't particularly large, and there was no real need to introduce the complexity that sharing it between copied instances would have created.
So if I didn't make it clear -- my opinion is that whether containers should be by value or by ref depends on the circumstances and that choice should be left to the programmer. Thus the question becomes what's the easiest way to provide both? Three options I see: 1) Write ref classes and wrap them in structs 2) Write value structs and wrap them in classes 3) Write template mixins and mix them into both struct and class shells. I think given the existence of "alias this" for structs, 1 is actually the best-supported paradigm. I think with that you should be able to value-ize a by-ref container class just by writing a post-blitter to copy the contents.
Doh! I didn't realize classes could "alias this" too! So that would put 1 and 2 on equal footing in that regard. But maybe one argument in favor of structs is that it is easier to take value semantics and turn it into ref semantics. You just need to take a pointer. So this: class RefContainer { alias this valContainer_; this() { valContainer =3D new ValueContainer; } private: ValueContainer *valContainer; } gets you a basic working ref container out of a value container. To this you will probably want to add copy or clone type functionality. In constrast: struct ValueContainer { alias this refContainer_; this() { refContainer =3D new RefContainer; } // must have add post-blit to get value semantics private: RefContainer refContainer; } The requirement to add the post-blit is a little annoying. If a ValueContainer is made fundamental and it is built initially out of components with value semantics, then no explicit post-blit will be necessary. However if you go the other way and start with a RefContainer then a post-blit will be necessary when you implement the ValueContainer based on it. So to me it seems a little better to go with the ValueContainer as the base implementation. --bb
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 The requirement to add the post-blit is a little annoying.  If a
 ValueContainer is made fundamental and it is built initially out of
 components with value semantics, then no explicit post-blit will be
 necessary.  However if you go the other way and start with a
 RefContainer then a post-blit will be necessary when you implement the
 ValueContainer based on it.   So to me it seems a little better to go
 with the ValueContainer as the base implementation.
I think it's a matter of the most frequent use. I used to be a staunch supporter of values for containers, until Walter revealed to me that in STL you have value containers to constantly worry about adding the "&" everywhere. Implicitly copying containers is 95% of cases an error in C++ code. Witness all that advice about pass by reference etc. So why make that the default, one might ask? Better go with the flow and make the default case the easy case (reference), and if someone does want a value, have them write Value!Container. Andrei
Jul 27 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 10:58 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 The requirement to add the post-blit is a little annoying. =A0If a
 ValueContainer is made fundamental and it is built initially out of
 components with value semantics, then no explicit post-blit will be
 necessary. =A0However if you go the other way and start with a
 RefContainer then a post-blit will be necessary when you implement the
 ValueContainer based on it. =A0 So to me it seems a little better to go
 with the ValueContainer as the base implementation.
I think it's a matter of the most frequent use. I used to be a staunch supporter of values for containers, until Walter revealed to me that in S=
TL
 you have value containers to constantly worry about adding the "&"
 everywhere. Implicitly copying containers is 95% of cases an error in C++
 code. Witness all that advice about pass by reference etc. So why make th=
at
 the default, one might ask? Better go with the flow and make the default
 case the easy case (reference), and if someone does want a value, have th=
em
 write Value!Container.
Hmm. Yeh, when passing containers around, 95% or more probably should be by ref. However when creating composite objects I'd say the percentage of time you want by ref is much lower. But I guess even then, by-ref composition isn't necessarily bad (as most VM languages show). --bb
Jul 27 2009
prev sibling next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Mon, 27 Jul 2009, Andrei Alexandrescu wrote:

 Bill Baxter wrote:
 The requirement to add the post-blit is a little annoying.  If a
 ValueContainer is made fundamental and it is built initially out of
 components with value semantics, then no explicit post-blit will be
 necessary.  However if you go the other way and start with a
 RefContainer then a post-blit will be necessary when you implement the
 ValueContainer based on it.   So to me it seems a little better to go
 with the ValueContainer as the base implementation.
I think it's a matter of the most frequent use. I used to be a staunch supporter of values for containers, until Walter revealed to me that in STL you have value containers to constantly worry about adding the "&" everywhere. Implicitly copying containers is 95% of cases an error in C++ code. Witness all that advice about pass by reference etc. So why make that the default, one might ask? Better go with the flow and make the default case the easy case (reference), and if someone does want a value, have them write Value!Container. Andrei
There's two layers to talk about, the container itself and the elements it contains. I agree that the container itself should be ref given the above logic (which matches my experience). The less obvious one, imho, is the default of the contained. Again, c++ uses value containership, but an awful lot of the time people (including myself) use essentially a ref (by way of a smart pointer). Often it's due to weak ownership semantics, and thus iffy design, but it is what it is. Later, Brad
Jul 27 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 27 de julio a las 12:58 me escribiste:
 Bill Baxter wrote:
The requirement to add the post-blit is a little annoying.  If a
ValueContainer is made fundamental and it is built initially out of
components with value semantics, then no explicit post-blit will be
necessary.  However if you go the other way and start with a
RefContainer then a post-blit will be necessary when you implement the
ValueContainer based on it.   So to me it seems a little better to go
with the ValueContainer as the base implementation.
I think it's a matter of the most frequent use. I used to be a staunch supporter of values for containers, until Walter revealed to me that in STL you have value containers to constantly worry about adding the "&" everywhere. Implicitly copying containers is 95% of cases an error in C++ code. Witness all that advice about pass by reference etc. So why make that the default, one might ask? Better go with the flow and make the default case the easy case (reference), and if someone does want a value, have them write Value!Container.
Another point for ref containers is that they allow to have a class hierarchy of containers. I guess you can have it too using compile-time "concepts", like ranges, but being able to do that with interfaces could be nice (and you can still have the compile-time with classes too). I don't know if the interfaces approach would be useful though... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- We're rotten fruit We're damaged goods What the hell, we've got nothing more to lose One gust and we will probably crumble We're backdrifters
Jul 27 2009
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Leandro Lucarella wrote:
 About values vs. reference semantics, I think reference is the best.
 Containers usually are big, and you don't want to copy them arround.
 I find myself using lots of references to pass containers arround in C++
 and almost never use the copy() method of Python containers, so based on
 *my* experience, I'd say that reference as the default is the best
 approach.
I don't think the choice of reference vs value semantics has *anything* to do with how often something is copied. To me, the relevant questions are: - Do you have strict ownership relationships? (Usually you do.) - Do you want to avoid long-distance bugs? (Yes you do, always.) Orthogonal question: does copying *ever* make sense: - If yes, provide a copy operation. - If no, prevent copying. -- Rainer Deyke - rainerd eldwood.com
Jul 27 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 27 Jul 2009 08:59:40 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Benji Smith wrote:
 For example, should the author of a container library prefer classes or  
 structs?
I've been struggling with this forever. I don't know. I don't even know whether reference or value semantics are best for containers. I don't know whether abstract container interfaces and container-independent code are a net win; experience with STL seems to say "don't" and experience with Java seems to say "ho-hum".
If you use classes with interfaces, then ranges can't be part of that equation. Since ranges are for the most part structs, and structs can't currently support interfaces, you can't make an interface that accepts a range. That's not to say ranges can't be part of classes, but they can't be part of interfaces. When making dcollections, I tried to separate out what should be part of the interface, and what should be specific to each class. What I found was that all the cursors (what you would call unsafe C++ iterators ;) ) could not be interface types, because they were structs for performance. However, I wanted to have the ability to have two different containers ineroperate seamlessly with eachother, as long as the types were the same. That suggested interfaces. What I ended up with is two ways to deal with container elements, opApply and cursors. I am biased of course, but I think it's the perfect combination of power, ease of use, and low cost of implementation. I still have yet to incorporate a range concept into my design, but I think it can be bolted on using a container with two cursors.
 Should other (non-container) modules accept container classes as  
 arguments? Or only container interfaces (if there are any such things)  
 or just ranges?
I think ranges should be preferred wherever applicable.
Ranges imply templated functions, which mean: - no polymorphism (although this requirement is questionable, most users don't derive from containers). - no usage of interfaces - each call may compile a new function (i.e. code bloat) There is something to be said with the power of opApply here, since you can do it with a class or interface, with very decent performance (only one virtual call). As I said earlier, a combination of both ranges and interfaces would be ideal. -Steve
Jul 27 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote:

 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
That's the problem. On one hand, it's desirable to see a module as a functionality bundle. On the other hand, module is the smallest available unit of encapsulation. That is, if you have a class and change its private implementation, this may affect *anything* in the same module. Hence Tango's hundreds of modules in dozens of packages, I think. It also adds to the problem that most people familiar with OO paradigm consider classes to be such encapsulation units. Surprizes are inevitable.
Jul 28 2009
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Sergey Gromov wrote:
 Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote:
 
 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
That's the problem. On one hand, it's desirable to see a module as a functionality bundle. On the other hand, module is the smallest available unit of encapsulation. That is, if you have a class and change its private implementation, this may affect *anything* in the same module. Hence Tango's hundreds of modules in dozens of packages, I think.
I guess that's meant to encourage you to keep your modules small enough that you know what you're doing. At the smallest level, it would be a matter of: If in C++ you would declare Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop in the same module. You could implement the converse as well, but for a bunch of small classes it usually isn't worth it.
 It also adds to the problem that most people familiar with OO paradigm
 consider classes to be such encapsulation units.  Surprizes are
 inevitable.
I once came up with the idea a 'veryprivate' protection attribute that would do this, but I can't seem to find the post now. Stewart.
Jul 28 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 28, 2009 at 4:42 PM, Stewart Gordon<smjg_1998 yahoo.com> wrote:
 Sergey Gromov wrote:
 Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote:

 Is it appropriate to define multiple classes, structs, templates, etc
 within a single module? What considerations should inform the decision
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it=
's up
 to the designer to decide what that entails.
That's the problem. =A0On one hand, it's desirable to see a module as a functionality bundle. =A0On the other hand, module is the smallest available unit of encapsulation. =A0That is, if you have a class and change its private implementation, this may affect *anything* in the same module. =A0Hence Tango's hundreds of modules in dozens of packages,=
I
 think.
I guess that's meant to encourage you to keep your modules small enough t=
hat
 you know what you're doing.

 At the smallest level, it would be a matter of: If in C++ you would decla=
re
 Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop in the s=
ame
 module. =A0You could implement the converse as well, but for a bunch of s=
mall
 classes it usually isn't worth it.

 It also adds to the problem that most people familiar with OO paradigm
 consider classes to be such encapsulation units. =A0Surprizes are
 inevitable.
I once came up with the idea a 'veryprivate' protection attribute that wo=
uld
 do this, but I can't seem to find the post now.
"super private" :-) Sorry I just can't let that old idea to call immutable "super const" die. It was just too darn cute. --bb
Jul 28 2009
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Wed, 29 Jul 2009 00:42:31 +0100, Stewart Gordon wrote:

 Sergey Gromov wrote:
 Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote:
 
 Is it appropriate to define multiple classes, structs, templates, etc 
 within a single module? What considerations should inform the decision 
 regarding the placement of module boundaries?
I think it's appropriate because many pieces of functionality come as a bundle. The rule of thumb is, module provides the functionality, and it's up to the designer to decide what that entails.
That's the problem. On one hand, it's desirable to see a module as a functionality bundle. On the other hand, module is the smallest available unit of encapsulation. That is, if you have a class and change its private implementation, this may affect *anything* in the same module. Hence Tango's hundreds of modules in dozens of packages, I think.
I guess that's meant to encourage you to keep your modules small enough that you know what you're doing.
Yes you can do a finer-grained encapsulation, but then you end up without "functionality bundle." And even if you create a collective import module I think there is no way to make it stand out as such. Though this is no different from C.
 At the smallest level, it would be a matter of: If in C++ you would 
 declare Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop 
 in the same module.  You could implement the converse as well, but for a 
 bunch of small classes it usually isn't worth it.
This is understandable.
 It also adds to the problem that most people familiar with OO paradigm
 consider classes to be such encapsulation units.  Surprizes are
 inevitable.
I once came up with the idea a 'veryprivate' protection attribute that would do this, but I can't seem to find the post now.
I wonder how much code will break if "private" keyword becomes really private. You can always implement tight coupling with package visibility which C++ lacks.
Jul 28 2009
prev sibling next sibling parent noobie <a b.com> writes:
With so much of work including the things others have mentioned, it looks like
the proper release date for a well polished D implementation should be 1.5 to 2
years from now. No?

Don Wrote:

 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
 
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
Jul 15 2009
prev sibling next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Don wrote:
 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
 
 Everyone knows there are a multitude of significant bugs in Bugzilla, 
 and most people have their pet list of minor language warts they hope 
 will be removed. But there's also some earthquake issues that have huge 
 implications. It's very disconcerting when some of them are introduced 
 in a casual manner. I think it would reduce a lot of frustation in the 
 community if we compiled an official list of the major ones. Here's a 
 few I came up with:
 
 - Multithreading (I): Will Bartosz's proposal be accepted (in some form)?
 - Multithreading (II): Will some form of message parsing be included?
 - Operator overloading. "completely redone" (?)
 - opImplicitCast
 - is T[new] still going to happen?
 - Phobos I/O -- Andrei has stated that he wants to completely rewrite it.
 - Unimplemented features -- safe D, contract inheritance.
 - Andrei once said that he wants to get rid of new (!)
 - The Tango license issue needs to be sorted to the extent that Andrei 
 and Walter feel they can safely look at the Tango code; OR we can decide 
 that's not going to happen, and change the strategy for the Tango/Phobos 
 relationship.
 
 The stuff on this list will either be implemented, or dropped. New 
 things could be added to the list. But we can gauge our progress towards 
 D2.0 by how rapidly the list shrinks with time.
 
 Which other major issues have I missed? Things which, if they happen, 
 will probably require major spec changes, major library redesign, or 
 break large amounts of code. Let's get everything on the table.
Bartosz wrote the following on his blog: Bartosz Milewski Says: July 20, 2009 at 2:59 pm To lvaro: Weve just had a conferenceAndrei, Walter and I. We decided that we have a deadline for D2, so we have to cut some features and postpone them to D3. The race-free type system wont make itthere just isnt enough time to implement and test it. There will be however a stopgap solution for message passing in Phobos. It will be limited but safe. Source: http://bartoszmilewski.wordpress.com/2009/07/16/on-actors-and-casting/#comments See comment 15. Perhaps Walter, would like to publish or confirm what is on the final list for D2. It would reduce confusion and rumour. cheers Nick B.
Jul 22 2009
parent Jason House <jason.james.house gmail.com> writes:
Sadly, this has been the writing on the wall for some time. For me, the
critical question for D2 is "How will unique be handled?". Andrei favors a
library-based struct-only solution (Where structs with non-immutable
pointers/references are disallowed)

I'm surprised to hear that Bartosz's ownership scheme wouldbe adopted at all. I
hope it does, I like it.

Nick B Wrote:
 
 Bartosz wrote the following on his blog:
 
 Bartosz Milewski Says:
 
 July 20, 2009 at 2:59 pm
 
 To lvaro: Weve just had a conferenceAndrei, Walter and I. We decided 
 that we have a deadline for D2, so we have to cut some features and 
 postpone them to D3. The race-free type system wont make itthere just 
 isnt enough time to implement and test it. There will be however a 
 stopgap solution for message passing in Phobos. It will be limited but safe.
 
 Source: 
 http://bartoszmilewski.wordpress.com/2009/07/16/on-actors-and-casting/#comments
 See comment 15.
 
 Perhaps Walter, would like to publish or confirm what is on the final 
 list for D2. It would reduce confusion and rumour.
 
 cheers
 Nick B.
Jul 22 2009
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Don wrote:
 A lot of frustration has been expressed on the newgroup about lack of a 
 clear public plan for D2.0. I don't think we're in a position to create 
 a road-map. But, let's at least agree on which countries we'll probably 
 visit before we reach our final destination <g>.
<snip> Indeed, we're still far from there. Some of the words have already been taken out of my mouth, but I shall add: - All of the still-unresolved spec issues inherited from D1. - Data integrity issues, such as holes in the const/invariant system. - Getting the Windows API bindings project completed and then dropped in. - Probably others I can't think of at the moment.... Stewart.
Jul 22 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
<snip>
 - Probably others I can't think of at the moment....
I've just remembered something else that ought to come soon, and certainly before the D2.0 finalisation: making it syntactically valid to use cent and ucent, as a first preparation for when these types are finally implemented. This'll be needed for both forward and backward compatibility. See http://d.puremagic.com/issues/show_bug.cgi?id=785 Stewart.
Jul 26 2009
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
Benji,
 
I did a little JSON parser too. Should we swap ideas?

Steve

 
 I suspect that my humble little JSON parser uses styles and idioms that 
 would clash with the majority of Phobos_2 (since my programming pedigree 
 comes from Java, C#, JavaScript, and Perl much moreso than C or C++).
 
 --benji
Jul 27 2009