On Sunday, 27 December 2020 at 23:18:37 UTC, Rekel wrote:

> Update;
> Any clue why there's both "std.file" and "std.io.File"?
> I was mostly unaware of the former.

The very first paragraph at the top of the `std.file` documentation explains it:

"Functions in this module handle files as a unit, e.g., read or write one file at a time. For opening files and manipulating them via handles refer to module std.stdio."

https://dlang.org/phobos/std_file.html

> http://ddili.org/ders/d.en/index.html

This seems very promising :)
I doubt I'd still be considering D if it weren't for this awesome learning forum, thanks for all the help!

On 12/26/20 7:13 PM, Rekel wrote:
> I'm trying to read a file with entries seperated by '\n\n' (empty line), with entries containing '\n'. I thought the File.readLine(KeepTerminator, Terminator) might work, as it seems to accept strings as terminators, since there seems to have been a thread regarding '\r\n' seperators.
> 
> I don't know if there's some underlying reason, but when I try to use "\n\n" as a terminator, I end up getting the entire file into 1 char[], so it's not delimited.
> 
> Should this work or is there a reason one cannot use byLine like this?
> 
> For context, I'm trying this with the puzzle input of day 6 of this year's advent of code. (https://adventofcode.com/)

Are you on Windows? If so, your double newlines might be \r\n\r\n, depending on what editor you used to create the input. Use a hexdump program to see what the newlines are in your input file.

Now, you would think that the underlying C stream would do this for you. I'm not sure how it works exactly, as I don't use Windows.

-Steve

On Tuesday, 29 December 2020 at 14:50:41 UTC, Steven Schveighoffer wrote:
> Are you on Windows? If so, your double newlines might be \r\n\r\n, depending on what editor you used to create the input. Use a hexdump program to see what the newlines are in your input file.

I've tried \r\n\r\n as well, which sadly also did not work.
Using vscode I have also switched between CRLF and LF, which also did not do the trick.
I'm getting the sense the implementation might have a specific workaround for \r\n / CRLF line-endings, though I haven't checked the sourcecode yet.

Note that this is not really a problem for me specifically, I've long used a different approach, however it seemed like a design issue. I'll try replicating this in isolation later, maybe something was wrong last time I tried.