Design question. Why can't I access next and previous siblings directly?

[B1Z0N]

Just a question on why this library design decision was made and whether there are plans to add that.

So I am talking about having something like node.NextOrDefault() and node.PrevOrDefault() instead of going to a parent of a node, finding it's index and iterating to index + 1 and index - 1.

Essentially I've seen someone just traversing whole SyntaxTree at the start and caching next and prev elements in a big dictionary to save some performance on looping.

[CyrusNajmabadi]

and whether there are plans to add that.

There are no plans to add this. :)

So I am talking about having something like node.NextOrDefault() and node.PrevOrDefault() instead of going to a parent of a node, finding it's index and iterating to index + 1 and index - 1.

We don't have support for that, as it is not core functionality, and would be trivial to add with an extension method. There's nothing we could do that would necessarily be better, and we certainly wouldn't want to increase the side of all nodes to contain this information.

Note: this definitely can not be stored at the green level. It would break incrementality (a node may have different siblings depending on what tree it is in). We could store it in the red level, but it would be very expensive (two extra pointers per node). That would bloat things massively. It also would have to be lazily realized (since we don't want to create the red nodes for siblings when walking down part of the tree). And the lazy realization would have nothing better to do than walking up, findign the index, and then getting the previous/next based on that index.

As such, this just adds expense, and complexity, with no perf gain. As such, it's better as an extension method written by a user if they want this sort of navigation mechanism.