Ugh the AOC is a bit of a wanker for putting an answer timer (sometimes I accidentally submit the example answer, and it takes 0.1s to fix but nooo you have to wait because the guy is retarded)

BTW I had to implement the parsing completely custom because of dynamically sized blocks, what did you guys do?

Wow, they're doing parsing there? Cool. Are you using a real lexer or lame regex?

I took the index range from one operator char to the next, read through that index in each previous line from top to bottom, skipped spaces, and folded up each digit d by 10*x+d

Custom parsing isn't bad, very often you can cut AoC tasks in half if you do the parsing in a slightly clever way.

It actually bothers me a lot that Rust is so insistent on avoiding positions in the string API. I get how it encourages correct string handling, but there's no rule that says &str[usize] can't return &str just because &str[usize..usize] returns &str.

Actually, it would be less error prone to support pulling a codepoint by a single index, because the default workaround people go for is &str[i..i+1] which panics on non-ASCII whereas the &str returned by &str[i] could be a single multiwide char.

@lorentz Agreed on that, it's the same with swift but there they don't even allow that workaround, they do have prefix/suffix functions though which is convenient.

I say "parser" but I'm also iterating based on the longest row (since on swift by default it seems to trim the space at the end)

Concat + replace " " + toInt on the column then stick that into a dynamic array

When done with that, I iterate the operators and add the relevant fold/reduce to an accumulator (granted, I could have done a double fold/reduce)

On the other hand, 5b can bite dirt, it took way too long and it was fully my fault. Range sequence processing has just a few too many cases to remember to handle all of them.

@lorentz Agreed, the way I ended up solving it was having a result list of ranges and just expanding all intersections with a count if multiple were expanded and if there were multiple then do a collapse (then sum all the ranges for the result), but I didn't want to do it that way originally

Haven’t done part 2 of day 6 yet but it looks like a nightmare to parse.
Will do tomorrow.

So far day 4,5,6 seemed a lot easier than day 1,2,3

@retoor the parsing is different for each day, but most of the time a simple splitBy("\n") and other separators is enough.

@BordedDev I used Itertools::coalesce, my absolute favourite iterator adapter, and indeed one of my favourite functions from any library. sort > coalesce > fold did it just fine. I just made an error in the coalescing (coalescence?) callback.

@Lensflare then it's more interesting than expected. Hmm.

@lorentz it’s incredible how much you can do with split, map, filter and reduce (fold).