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.

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

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

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

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

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

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

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

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

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.