[smallnamespace]

Because your code is actual running serially so no matter what there is an iteration order, and the order matters for performance even if your code does not care.

For example if you literally don’t care about the order then your code can map over a default iterator that is efficient (DFS).

[naasking]

Not true due to parallelism. Also, SQL demonstrates that you can describe the desired result declaratively without being concerned about iteration order. I see SQL's CTEs as a good example of the kind of primitive the article is talking about.

[alterom]

Sure, and perhaps that's the reason why we don't have a built-in for_tree: for some people, order matters; for others, it doesn't.

Then, for some cases, depth-first traversal is needed; for others, breadth-first.

Then, there's parallelism, and even the plain old for loops aren't parallel by default.

By the time you specify exactly what you need from a tree traversal, you've written code to do it.

And if you're fine with some default choice — you already can use the default iterator with the for_each loop.

I don't see what need there is for adding an extra for_tree syntax to do that.