persistent byLine

[Nick Treleaven]

On 23/07/2013 17:13, Nick Treleaven wrote:
> On 23/07/2013 00:28, Jonathan M Davis wrote:
>> On Monday, July 22, 2013 13:08:05 Nick Treleaven wrote:
>>> I made a pull request to re-enable using byLine!(char, immutable char).
>>> (Note this compiled in the current release, but didn't work properly
>>> AFAICT. It did work by commit 97cec33^).
>>>
>>> https://github.com/D-Programming-Language/phobos/pull/1418
>>>
>>> Using that allows us to drop the map!(l => l.idup) part from the above
>>> snippet. The new syntax isn't much better, but it can also be more
>>> efficient (as it caches front). I have an idea how to improve the
>>> syntax, but I'll omit it for this post.
>>
>> I agree with monarch in that we really shouldn't try and mess with
>> byLine like
>> this. It would just be cleaner to come up with a new function for
>> this, though
>> I confess that part of me thinks that it's better to just use map!(a =>
>> a.idup)(), because it avoids duplicating functionality. It is arguably
>> a bit
>> ugly though.
>
> I think I'll close that PR then. I reiterate that the readText.splitter
> approach is perhaps usually more efficient than either byLine/map/idup
> or byLine!(char, immutable char). Unless e.g. byLineDup was implemented
> so it allocated more than one line at once.

Although, the caller might not want all the file contents to hang around 
just because one line was needed, so I think byLineDup probably is 
needed too. It's good to have a range of options.

I might make a PR for byLineDup sometime, unless anyone beats me to it.

>>> I've since thought that if most or all lines in a file need to be
>>> persistent, it may be more efficient to use
>>> readText(filename).splitLines, because that doesn't need to allocate for
>>> each line.
>>>
>>> There are two enhancements for that approach:
>>> 1. readText should accept a File, not just a filename, so we can use
>>> stdin.
>>
>> I'm opposed to this. I don't think that std.file should be using
>> std.stdio.File
>> at all. What we really need is for std.io to be finished, which will
>> revamp
>> std.stdio and give us streams and the like. And std.file really is not
>> designed
>> around using stdin - and shouldn't be IMHO. It's for operating on
>> actual files.
>
> Yes, I meant add std.stdio.File.readText. Would that be OK to add now,
> or is std.io likely to be added relatively soon?

Also is there any info on std.io? I assume it's still worthwhile to 
update std.stdio docs and fix issues?