March 17, 2014
On Mon, Mar 17, 2014 at 05:10:00AM +0100, Marco Leise wrote:
> Am Sun, 16 Mar 2014 18:03:09 +0000
> schrieb "Adam D. Ruppe" <destructionator@gmail.com>:
> 
> > 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.
> 
> Yes, pointers to working buffers are a frequent use case for "borrowed pointers".
[...]

Just out of curiosity: what's holding up the implementation of scope? It's been a long while since everybody has been clamoring for scope; isn't it about time we got our heads together to find a solution?


T

-- 
All problems are easy in retrospect.
March 17, 2014
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!
>
>
> Andrei

`f.lines` mentioned in a couple other posts seems straightforward and easy to remember.

Joseph
March 17, 2014
Just brainstorming:

f.splitByLine() or f.splitLines()

byLine -> process the file line by line
splitByLine -> split the file into lines
March 17, 2014
f.copyLines // A bit less awkward than "f.byLinesCopy" IMO.

On Monday, 17 March 2014 at 07:13:49 UTC, safety0ff wrote:
> Just brainstorming:
>
> f.splitByLine() or f.splitLines()
>
> byLine -> process the file line by line
> splitByLine -> split the file into lines

March 17, 2014
Dmitry Olshansky:

> f.lines?

There is already a lines in std.stdio (but I don't use it much), search for:

foreach (string line; lines(stdin))

Here:
http://dlang.org/phobos/std_stdio.html

Bye,
bearophile
March 17, 2014
On 16/03/2014 18:03, Adam D. Ruppe wrote:
> 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)

It would certainly help when using foreach. I think there are cases without foreach which would still be allowed to access previous range fronts though, as they could still be in scope.
March 17, 2014
> Depends on the situation. Consider a D tutorial. It would feature little programs like "copy a file" or "put each line in a hashtable" etc.
>
>> Anyway
>> byLineCopy or
>> byLineCopied
>> sounds natural for me (native german).

Another idea:
byLineDuplicate

Might be a bit (too) long, but probably could help leading to the topic of dup/idup and the like.
March 17, 2014
On 2014-03-16 10:31 PM, Etienne Cimon wrote:
>
> auto ln = f.split("\n", 15); // returns a gc allocated array of 15 lines

Moving it to a template and rethinking the naming

auto lines = f.splitLn!15; // returns 15 lines
auto lines = f.split!";" // splits the file using ; sep
auto lines = f.splitLn

I consider this to be an essential part of file reading, not necessarily line separation but moving the file pointer forward a number of elements with a choice of characters.
March 17, 2014
On 2014-03-16 12:58 PM, 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!
>
>
> Andrei

.explode()

i saw it in PHP ;)
March 17, 2014
On Mon, Mar 17, 2014 at 03:52:48PM -0400, Etienne wrote:
> On 2014-03-16 12:58 PM, 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!
> >
> >
> >Andrei
> 
> .explode()
> 
> i saw it in PHP ;)

Ew. If I wanted to go the PHP route, I'd go for .detonate() instead -- at least there's a D in there! :-P

But what type would .explode() return? std.stdio.File.Explosion? :-P


T

-- 
It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca