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



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:


 crap)




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 


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



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. 

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

 
 --benji
Jul 27 2009