[phobos] What's the status of listDir/listdir ?

[Dmitry Olshansky]

On 10.06.2011 23:04, Jonathan M Davis wrote:
> On 2011-06-10 09:21, Jonathan M Davis wrote:
>> On 2011-06-10 05:22, Dmitry Olshansky wrote:
>>> On 10.06.2011 16:19, Andrei Alexandrescu wrote:
>>>> On 6/10/11 4:47 AM, Jonathan M Davis wrote:
>>>>> The main problem with dirEntries is essentially as you point out. It
>>>>> doesn't
>>>>> work with anything but foreach. You can't even pass it to
>>>>> std.array.array to
>>>>> create an array. And it's because it's set up to work with either a
>>>>> string or
>>>>> a DirEntry for the loop variable. The advantage of listdir/listDir is
>>>>> that you
>>>>> get an actual array of strings to use when you need to pass it to
>>>>> something.
>>>>> Ideally, DirIterator wolud be made to work with more, but it hasn't
>>>>> been. I
>>>>> don't know if we want to try and turn it into a range or what, but it
>>>>> is a bit
>>>>> of a problem if you want to use dirEntries outside of a foreach loop.
>>>> Any chance of somebody finding the time to transform dirEntries into
>>>> an input range? That would solve everything.
>>> I decided to try just that. It will take some time though.
>> The only thing that I can think of doing is making it so that DirIterator
>> is a range with element type DirEntry and make DirEntry have an alias this
>> to its name property. I _think_ that that will give the same behavior as
>> the current behavior. Certainly, I don't know how else we'd do it. The
>> ability to have multiple iteration types for the same range is not exactly
>> one of ranges strong points.
> The more I think about it, the more I think that this is the correct solution.
> I just don't see any other way to do it. And it should actually be pretty easy
> to do. The main question is whether we want to mess with DirIterator's
> internals with regards to _listDir and its delegate solution. And that's
> completely up to you, but I think that I'd be inclined to leave it alone for
> the moment (probably until listdir and listDir are gone), since it's fewer
> changes and fewer places to introduce bugs.
>
> - Jonathan M Davis
For now I going this route, namely, reconstructing DirIterator as an 
input range, leaving all listDir functionality as is.
As a bonus dirEntries won't overflow stack because of recursion (thought 
admittedly it's a corner case).
And yes, I see no other way then to add  alias this to DirEntry, to make 
this change compatible with current API.

-- 
Dmitry Olshansky