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.

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


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.

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

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


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.

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


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.

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

 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast

I think alias this should render that unnecesary.

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

 On Tue, Jul 14, 2009 at 12:42 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 - opImplicitCast

I think alias this should render that unnecesary.

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 next sibling 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 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.
 [...]

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 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
prev sibling next 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 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=

'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=

 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=


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 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 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: We’ve just had a conference–Andrei, 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 won’t make it–there just isn’t 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: We’ve just had a conference–Andrei, 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 won’t make it–there just 
 isn’t 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 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>.

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