Finalizing D2

[Jason House]

Would it be a good idea to transcribe this list onto a "Phobos Help Wanted" 
page?

I'm thinking they should be categorized into 4 basic categories.  
Theoretically, as time goes on higher numbered items should be convertible 
to lower numbered items.

1. Pure library work
   -> Should include basic status info such as:
      "Nobody is working on it"
      "As of XXXX, Mr. Z. has started working on a patch"
      "Andrei has said D2 Phobos needs this"
2. Blocked or partially blocked by bugzilla issues
   -> Should list a bugzilla link for the issues limiting the implementation
   -> Each issue should have a basic status info such as:
      "Nobody is working on it"
      "As of XXXX, Mr. Z. has started working on a patch"
      "Andrei confirmed with Walter this fix is worthwhile for D2"
      etc...
3. Mostly requires discussion / agreement within the community
   -> Links to relevant threads on the D newsgroup (with two lines of recap)
4. Language design work
   -> Links to relevant threads on the D newsgroup
   -> Short paragraphs with design ideas (may need to be on a separate page)


I'd imagine items 3 and 4 would inspire discussions on the newsgroup for 
ironing out the details.  Below, I reordered your list with an initial cut 
at categories.  There are a few category 1 items that are in there simply 
because there's so much rework to be done that I doubt anyone would complain 
about any attempt to clean it up.  For smaller tweaks (such as where to move 
something), I put it into category 3 since little stuff is more likely to 
generate opinions.


Andrei Alexandrescu wrote:

> Jason House wrote:
>> What do you / others consider the weakest / missing parts of Phobos?
> 
> Wow. Where should I start. Let me go down the list of modules and share
> a few thoughts.


category 1 (pure library work)
---------------------------------
> * std.base64: doesn't deserve a separate module
> * std.bitmanip: define a range for BitArray and eliminate opApply. Add
> opSlice.
> * std.complex: IMPLEMENT. Eliminate any trace of built-in complex.
> * std.conv: define operations to stream data out and in in binary and
> text formats.
> * std.encoding, std.utf: we need a massive overhaul of all
> encoding-specific stuff. Massive. Epic. The current pile of...
> functionality makes the simplest stuff look like rocket surgery.
> * std.md5: we should add more such encryption devices.
> * std.metastrings: I hate the name. Merge into std.string using ctfe
> * std.mmfile: integrate with the garbage collector. It should be there.
> * std.process: add pipe() for Windows. Actually that should be in stdio.
> * std.regex, std.regexp: merge and finalize.
> * std.socket, std.socketstream: We need a real networking library.
> * std.stdio: implement readf and various I/O specific ranges
> * std.thread: replace
> * std.variant: add dynamic method invocation capabilities
> * std.xml: replace with something that moves faster than molasses.
> * std.zip: rewrite


category 2 (Blocked by bugzilla issues)
---------------------------------


category 3 (requires community discussion)
---------------------------------
> * std.bind: eliminate?
> * std.vendor: should this go in core?
> * std.cover: another little module that should be merged somewhere
> * std.date: unnecessarily clunky and low-level. Also, somehow Walter
> thinks that std.dateparse has absolutely nothing to do with date.
> * std.demangle: another small module. Should be merged with e.g. other
> compiler-specific stuff.
> * std.outbuffer: I think this shouldn't be a class and shouldn't have
> that name.
> * std.outofmemory: why???
> * std.signals: I don't know much. A review wouldn't hurt.
> * std.cstream, std.stream: eliminate.
> * std.string: arrange so there's no overlapping/conflict with
> std.algorithm. Implement bidir range for reading strings correctly
> (already done that).
> * std.system: merge somewhere

category 4 (language design work)
---------------------------------
> * std.array: we need to make a decision about differentiating arrays
> from slices.