Phobos Wish List/Next in Review Queue?

[dsimcha]

On 11/20/2011 12:30 PM, Jonas Drewsen wrote:
>> * Containers. (AFAIK noone is working on this. It's tough to get started
>> because, despite lots of discussion at various times on this forum,
>> noone seems to really know what they want. Since the containers in
>> question are well-known, it's much more a design problem than an
>> implementation problem.)
>  >
>> * Allocators. (I think Phobos desperately needs a segmented stack/region
>> based allocator and I've written one. I've also tried to define a
>> generic allocator API, mostly following Andrei's suggestions, but I'll
>> admit that I didn't really know what I was doing for the general API.
>> Andrei has suggested that allocators should have real-world testing on
>> containers before being included in Phobos. Therefore, containers block
>> allocators and if the same person doesn't write both, there will be a
>> lot of communication overhead to make sure the designs are in sync.)
>
> I've though about doing some containers myself but have hesitated since
> the general opinion seem to be that allocators need to be in place first.

Yeah, this is problematic.  In voting against my allocator proposal, 
Andrei mentioned that he wanted the allocators to be well-tested in the 
container API first.  This means either we have a circular dependency or 
allocators and containers need to be co-developed.  Co-developing them 
is problematic.  If one person does containers and another allocators, 
the project might be overwhelmed by communication overhead.  If the same 
person does both, then this is asking a pretty lot for a hobby project.

Of course, I hope to graduate in <1 year and will be looking for a job 
when I do.  Any company out there have a strategic interest in D and 
want to hire me to work full-time on allocators and containers?

>> * Streams. (Another item where the bottleneck is mostly at the design
>> level and people not really knowing what they want.)
>
> What does streams provide that could not be provided by ranges?

If I understand correctly, streams _would_ be a flavor of ranges.  They 
would just be ranges that are geared towards being stacked on top of one 
another specifically for the purpose of I/O.  They would typically be 
design around the vanilla input range (not forward, random access, etc.) 
or output ranges.

Traditionally, streams would also be class based instead of template 
based.  However, IMHO a good case can be made for template based stream 
ranges in D because we have std.range.inputRangeObject and 
std.range.outputRangeObject.  This means that you can stack streams 
using templates, with no virtual function call overhead, and then if you 
need to respect some binary interface you could just stack an 
inputRangeObject() or outputRangeObject() on top of all your other crap 
and only have one virtual call.  Example:

auto lines = lineReader(
     gzipUncompresser(
         rawFile("foo.gz")
     )
);

// LineReader!(GzipUncompresser!(RawFile)))
pragma(msg, typeof(lines));

auto objectOriented = inputRangeObject(lines);

// InputRangeObject!(char[])
pragma(msg, typeof(objectOriented));