#AdventOfCode #Day3
-
Soooo... I think my "high-level brain" is starting to conflict with #rust.
This works, but:
* clippy wants to me to rewrite a loop to use iterators, but I don't get why it'd be better
* I think I should be using pass-by-reference rather than values in a few places
* that type on my parse function looks scary
* I am using Vec but this all looks pretty static so I feel it should all be arrays? dunno.
* I miss named argumentshttps://gist.github.com/riffraff/d674119aa3740275967fd6f14b77cba6
-
Soooo... I think my "high-level brain" is starting to conflict with #rust.
This works, but:
* clippy wants to me to rewrite a loop to use iterators, but I don't get why it'd be better
* I think I should be using pass-by-reference rather than values in a few places
* that type on my parse function looks scary
* I am using Vec but this all looks pretty static so I feel it should all be arrays? dunno.
* I miss named argumentshttps://gist.github.com/riffraff/d674119aa3740275967fd6f14b77cba6
@riffraff I think clippy just wants you to avoid you using indexing. You can mix for loops with iterators. So for example use `for value in numbers.iter().take(wanted) {` instead of the range. Which also makes the calculation of `end` easier to understand.
-
@riffraff I think clippy just wants you to avoid you using indexing. You can mix for loops with iterators. So for example use `for value in numbers.iter().take(wanted) {` instead of the range. Which also makes the calculation of `end` easier to understand.
@tamme indeed, but I do want the index in this case (it's part of the return value), so I need enumerate() and max_by_key() and at that point it becomes messier to my eyes 🤷♂️
EDIT: although I guess I can use enumerate and the same max, and that's what you meant with mixing for an iterators 🤔 -
Soooo... I think my "high-level brain" is starting to conflict with #rust.
This works, but:
* clippy wants to me to rewrite a loop to use iterators, but I don't get why it'd be better
* I think I should be using pass-by-reference rather than values in a few places
* that type on my parse function looks scary
* I am using Vec but this all looks pretty static so I feel it should all be arrays? dunno.
* I miss named argumentshttps://gist.github.com/riffraff/d674119aa3740275967fd6f14b77cba6
-
Soooo... I think my "high-level brain" is starting to conflict with #rust.
This works, but:
* clippy wants to me to rewrite a loop to use iterators, but I don't get why it'd be better
* I think I should be using pass-by-reference rather than values in a few places
* that type on my parse function looks scary
* I am using Vec but this all looks pretty static so I feel it should all be arrays? dunno.
* I miss named argumentshttps://gist.github.com/riffraff/d674119aa3740275967fd6f14b77cba6
@riffraff the type isn't so bad, though if it gets larger you could consider a type alias.
max_bankcould probably take a&[u64]letting you get rid of some of the vecs that are indeed not necessary. That also gets you the pass by reference you mentioned. For integers you never need to pass by reference since they're Copy. But it looks like you already knew that :) A vec is only necessary the first time when you deal with input since that's pretty dynamic. Then in the rest of your code you're just reading from that one vec, not necessarily growing it so a slice&[T]is enough. Note that a slice isn't quite the same as an array. A slice borrows some number of elements from a container like an array or vec. An array ([T; N]) is different in that its size is fixed at compile time. An array of 4 elements is pretty much equivalent to 4 values in different local variables, of the same type passed together in a single variable.If you like named arguments, sometimes passing a struct can be nice. Note that you can destructure structs in argument position, so
struct Args{...} fn foo (Args {a,b,c}: Args){...}Though here I'm not sure I'd go for that.Rewriting a loop to iterators can sometimes be slightly faster, but I'd say what you do here is pretty good. Clippy is not always correct! It's trying to teach you something but in the end it's just a bunch of heuristics, it's not always right!
-
@riffraff the type isn't so bad, though if it gets larger you could consider a type alias.
max_bankcould probably take a&[u64]letting you get rid of some of the vecs that are indeed not necessary. That also gets you the pass by reference you mentioned. For integers you never need to pass by reference since they're Copy. But it looks like you already knew that :) A vec is only necessary the first time when you deal with input since that's pretty dynamic. Then in the rest of your code you're just reading from that one vec, not necessarily growing it so a slice&[T]is enough. Note that a slice isn't quite the same as an array. A slice borrows some number of elements from a container like an array or vec. An array ([T; N]) is different in that its size is fixed at compile time. An array of 4 elements is pretty much equivalent to 4 values in different local variables, of the same type passed together in a single variable.If you like named arguments, sometimes passing a struct can be nice. Note that you can destructure structs in argument position, so
struct Args{...} fn foo (Args {a,b,c}: Args){...}Though here I'm not sure I'd go for that.Rewriting a loop to iterators can sometimes be slightly faster, but I'd say what you do here is pretty good. Clippy is not always correct! It's trying to teach you something but in the end it's just a bunch of heuristics, it's not always right!