Developing a plan for D2.0: Getting everything on the table
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Wed Jul 22 18:55:54 PDT 2009
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
More information about the Digitalmars-d
mailing list