A modern programming language that makes developers happier.

kotlinlang

Screen Shot 2022-12-02 at 9.40.59 am.png

Friendly reminder to turn this off :sweat_smile: it was adding extra `\n` to the imported `.txt`s

all the files served by <http://adventofcode.com|adventofcode.com> are proper UNIX text files, meaning they are `\n`-terminated to begin with

<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_403>
&gt; A file that contains characters organized into zero or more lines.
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206>
&gt; A sequence of zero or more non- &lt;newline&gt; characters plus a terminating &lt;newline&gt; character.
a non-empty file that does not end in a newline is not a text file

If you have a utility function to read files you can add .trim() to it to remove the extra line

the thing with `\n` terminated last lines (and I am a big fan of it, and wouldn’t have it any other way) is that `String.lines()` always end up with an empty string at the end, so it’s best to add `.filter(String::isNotBlank)`.

While we're at it, should that be filed as a bug of `lines()` ? We clearly don't expect a terminal `LF`  character to represent an empty line.

Nonono, we expect lines() to behave similar to split("\n"), which wold give us empty string at the end. And even if not, it's too late to change that now after 10 years, that would be too breaking change for existing code.

I understand the backwards compatibility argument, but it's still going to be a weird thing everyone stumbles upon.

note that `readLines()`/`useLines()` do not have this issue: they handle a terminal EOL just fine

so if you use those instead of `split()` or `lines()` then you have nothing to worry about

```"a\nb\nc\n".lines() == listOf("a", "b", "c", "")
"a\nb\nc\n".reader().readLines() == listOf("a", "b", "c")```
although it is more natural to use `readLines()` on a `File` than on a `String`