byLineWithCopy?
byCopiedLine?
byLineWithGarbage?

It's a hard thing to name.

Andrei Alexandrescu:

>> "byDupLines"
>
> It introduces the notion of "dup" to newbies. I'd rather go with a natural name.

In Python you write:

for line in file("text.txt"):
    ...


So can't you make File iterable?

foreach (line; "text.txt".File) {}

Bye,
bearophile

On Sunday, 16 March 2014 at 17:53:58 UTC, Andrei Alexandrescu wrote:
> On 3/16/14, 10:52 AM, Jakob Ovrum wrote:
>> Seems like the definition of a trivia function.
>
> Trivial + frequent = good
>
> see assert, enforce, ~, and many others.
>
> Andrei

Fine. I'm guilty of still being in the camp that doesn't think a copying `byLine` is strictly needed, but I understand the pragmatism at play.

On Sunday, 16 March 2014 at 17:58:45 UTC, bearophile wrote:
> In Python you write:
>
> for line in file("text.txt"):
>     ...
>
>
> So can't you make File iterable?
>
> foreach (line; "text.txt".File) {}
>
> Bye,
> bearophile

Is `line` a byte, a character, or a line?

If byLine returned a scope item, then it wouldn't be allowed to escape and throw a nice compile error pointing people in the right direction.... scope rox so much i want it so badly. (i guess here the mutability pretty much tells the story too tho)


But going with the idea that the duplicated one can be escaped/stored:

f.byLineStorable

or something like that. The name tells you that it is cool to store each line.

On Sunday, 16 March 2014 at 16:58:36 UTC, Andrei Alexandrescu wrote:
> A classic idiom for reading lines and keeping them is f.byLine.map!(x => x.idup) to get strings instead of the buffer etc.
>
> The current behavior trips new users on occasion, and the idiom solving it is very frequent. So what the heck - let's put that in a function, expose and document it nicely, and call it a day.
>
> A good name would help a lot. Let's paint that bikeshed!

For the record, if you want to keep all lines in memory anyway, it's more efficient to just read the whole file at once then split it with splitLines(), because you avoid doing one memory allocation per line. The downside is if you want to keep only some of the lines on the heap in a long-running program - with this approach, the slices pin the entire file content.

Jakob Ovrum:

> Is `line` a byte, a character, or a line?

It's a line, as in all Python programs :-)

Note Jakob Ovrum that Andrei is asking for something for newbies. Otherwise for all other D programmers byDupLine is fine.

Bye,
bearophile

On Sunday, 16 March 2014 at 18:06:00 UTC, Vladimir Panteleev wrote:
> On Sunday, 16 March 2014 at 16:58:36 UTC, Andrei Alexandrescu wrote:
>> A classic idiom for reading lines and keeping them is f.byLine.map!(x => x.idup) to get strings instead of the buffer etc.
>>
>> The current behavior trips new users on occasion, and the idiom solving it is very frequent. So what the heck - let's put that in a function, expose and document it nicely, and call it a day.
>>
>> A good name would help a lot. Let's paint that bikeshed!
>
> For the record, if you want to keep all lines in memory anyway, it's more efficient to just read the whole file at once then split it with splitLines(), because you avoid doing one memory allocation per line. The downside is if you want to keep only some of the lines on the heap in a long-running program - with this approach, the slices pin the entire file content.

Reading all at once is also a problem for really big files.

copyByLine

Andrei Alexandrescu:

> A classic idiom for reading lines and keeping them is f.byLine.map!(x => x.idup) to get strings instead of the buffer etc.

Once dup/idup become free functions in object you can also write:

f.byLine.map!idup

Bye,
bearophile