The codebase is generics-heavy and a usual pattern is that an algorithm, operator, etc. constraints the generic types by core traits (e.g., VerticesBase, Edges<E, Ty>, etc, such that it can provide the desired functionality. Among related traits, there is usually some kind of relation such that one trait makes stronger demands on the type than the other. The relations are:
VerticesBase -- (adds data V) --> Vertices<V> -- (adds mutation) --> VerticesMut<V>, and similarly for edges
standard traits make stronger demands than their "weak" counterparts, e.g., VerticesBase::vertex_count returns usize while VerticesBaseWeak::vertex_count_hint`` returnsOption`
The code has gone through a lot of changes and some of these traits were added on the way. There are probably places where the constraints are unnecessarily strong and relaxing them would make the bounds simpler or more widely applicable.
The codebase is generics-heavy and a usual pattern is that an algorithm, operator, etc. constraints the generic types by core traits (e.g.,
VerticesBase,Edges<E, Ty>, etc, such that it can provide the desired functionality. Among related traits, there is usually some kind of relation such that one trait makes stronger demands on the type than the other. The relations are:VerticesBase-- (adds data V) -->Vertices<V>-- (adds mutation) -->VerticesMut<V>, and similarly for edgesVerticesBase::vertex_countreturnsusizewhileVerticesBaseWeak::vertex_count_hint`` returnsOptionThe code has gone through a lot of changes and some of these traits were added on the way. There are probably places where the constraints are unnecessarily strong and relaxing them would make the bounds simpler or more widely applicable.