pro: functions pre and post are called in the order they would be in a normal dfs, so random example of something you could do with this, but not with current pre-post order Vec's: keep track of DFS stack for O(1) offline kth-par
con: you can't modify the actual adjacent list var inside the closure; so this can't be used for HLD
on a side note; using unnecessary space (the Vec which stores pre,post order) kinda bugs me - this is the motivation for doing it instead with closures: also this way with closures is more functional. For the same reason, I think we should switch https://github.com/programming-team-code/programming_team_code_rust/blob/main/src/numbers/primes.rs#L53 to calling closure on each prime factor instead of returning array
pro: functions
preandpostare called in the order they would be in a normal dfs, so random example of something you could do with this, but not with current pre-post order Vec's: keep track of DFS stack for O(1) offline kth-parcon: you can't modify the actual adjacent list var inside the closure; so this can't be used for HLD
on a side note; using unnecessary space (the Vec which stores pre,post order) kinda bugs me - this is the motivation for doing it instead with closures: also this way with closures is more functional. For the same reason, I think we should switch https://github.com/programming-team-code/programming_team_code_rust/blob/main/src/numbers/primes.rs#L53 to calling closure on each prime factor instead of returning array