graph: Graph.AddNode is subtly unsafe
kortschak opened this issue · comments
When I was writing the tests for the Bron-Kerbosch clique finding function I stumbled across a behaviour/user interaction that I think we should avoid.
The documentation for Graph.AddNode states that adding a node that already exists replaces the node, this is at odds with the name "add" and how that is normally interpreted.
The situation was that in constructing the test graph from the input data I did not check for existence of u nodes in a directed pair from a []search.set, thus overwriting v nodes in cases where subsequent edges where v < u. This gave obviously unexpected test results and because there is no noisy response to doing this, it took a fair bit of debugging to remember that nodes are replaced (this prompted #36 for the Tarjan tests which just happen to be in a forward order and so don't fail - by luck). In the case where a client is perhaps even less well versed in the graph package, this would be very frustrating.
I don't think the current behaviour is tenable in the long term.
In line with the general approach in gonum packages we should either disallow node replacement noisily or make AddNode to an existing node a no-op.
- Panic on adding an existing node after having replaced it. This allows existing behaviour after a recover. I think this is awful.
- Do a no-op and require that node replacement be a RemoveNode/AddNode pair. This explicitness fits well with the broader gonum approach for explicitness. Possibly this would return a
added bool, indicating whether a node had been added.
On further thought, I think 1. is probably the better option, without replacement. We are not adding a node, so we should not say that we are.