There are cases (1) when it would be useful to be able to iterate over all multi-edges between two vertices without requiring an additional trait bound on the input graph not to disqualify graphs that do not support that.
We might move multi_edge_index method from MultiEdges to Edges so that it can be used on all types implementing Edges. The trait MultiEdges would become a marker trait, if there is a need for constraining a graph on that. For graphs without multi-edge support, the MultiEdgeIndicesIter type would simply be Option<EdgeIndex> and the implementation would call edge_index.
We might even stop distinguishing between edge_index and multi_edge_index and have just edge_index that returns an iterator. With the current API, surprises may happen if a developer/user does not realize that edge_index does not tell the whole truth in multi-edge graphs. Therefore this change would reduce a chance for surprising behavior, which is one of our goals.
There are cases (1) when it would be useful to be able to iterate over all multi-edges between two vertices without requiring an additional trait bound on the input graph not to disqualify graphs that do not support that.
We might move
multi_edge_index
method fromMultiEdges
toEdges
so that it can be used on all types implementingEdges
. The traitMultiEdges
would become a marker trait, if there is a need for constraining a graph on that. For graphs without multi-edge support, theMultiEdgeIndicesIter
type would simply beOption<EdgeIndex>
and the implementation would calledge_index
.We might even stop distinguishing between
edge_index
andmulti_edge_index
and have justedge_index
that returns an iterator. With the current API, surprises may happen if a developer/user does not realize thatedge_index
does not tell the whole truth in multi-edge graphs. Therefore this change would reduce a chance for surprising behavior, which is one of our goals.