input to generator function seems to be missing trailing newlines about cargo-aoc

[gobanos]

Hum, input is trimmed to ease parsing (for example, when parsing a number on each line) here :

cargo-aoc/aoc-runner/src/lib.rs

Line 17 in 52164ce

ArcStr(Arc::from(f.trim_end_matches('\n')))

There is currently no way to turn it off :/

[tsheinen]

Oh okay, I missed that while I was looking through the source. It might be worth mentioning that in the readme (or adding a way to turn it off) since it threw me for a loop this morning. My parser depended on a trailing newline for each passport and although it was easy enough to fix I didn't realize I needed to do that.

[tsheinen]

What would be the use case for stripping the trailing newline? str::lines is probably the best way to split a string like this into lines and it gives the same result with and without a trailing newline.

[gobanos]

You're right, a flag to prevent trimming could be nice. After a glance at some old inputs, it still seems like a good default to me.

[aldanor]

I would go as far as saying it would make sense to not trim anything at all - because otherwise a solution that works without cargo-aoc may not work with it, and vice versa.

[dnlmlr]

So I'm pretty much zombifying this issue, but this behavior is absolutely unexpected and should not be the default imo.

Trimming the input in your solution or a generator function is literally one line, if you actually need it. Efficiently untrimming the input on the other hand is pretty much impossible without bad hacks.

This breaks for example a possible optimized solution with array_chunks::<4>() for aoc2022 day2. All lines consist of a structure like A X\n, which is exactly 4 bytes. When the trailing newline is trimmed, this skipps the last line and stops working.