The tracking issue for #551 (2) + (3).

Traits

Existing

• data::Build

  • Proposal: Trait Rework: Graph fundamentals #556

• data::Create

  • Proposal: Trait Rework: Graph fundamentals #556

• data::DataMap

  • Proposal: Trait Rework: Graph fundamentals #556

• data::DataMapMut

  • Proposal: Trait Rework: Graph fundamentals #556

• data::ElementIterator

  • ???

• data::FromElements

  • can be replaced with FromIterator<Item = Element<N, E>>

• visit::ControlFlow

  • Can be replaced with ControlFlow (available since 1.55)

• visit::Data

  • Proposal: Trait Rework: Graph fundamentals #556

• visit::EdgeCount

  • Problem: the ecosystem uses len() for length (with traits like TrustedLen), count() meanwhile is used in iterators which consumes the iterator
  • Proposal: Trait Rework: Unify *Count into GraphLen #554

• visit::EdgeIndexable

  • Proposal: Trait Rework: GraphPrimitiveIndex #555

• visit::EdgeRef

  • Proposal (6)

• visit::FilterEdge

  • Problem: FilterEdge sounds like it is used over a Graph to filter edges (e.g. g.filter()), instead it is used in
    EdgeFiltered.
  • Proposal: Trait Rework: Subgraph crate #553

• visit::FilterNode

  • Problem: FilterNode sounds like it is used over a Graph to filter nodes (e.g. g.filter()), instead it is used in
    NodeFiltered.
  • Proposal: Trait Rework: Subgraph crate #553

• visit::GetAdjacencyMatrix

  • Proposal: Trait Rework: AdjacencyMatrix #558

• visit::GraphBase

  • Proposal: Trait Rework: Graph fundamentals #556

• visit::GraphRef

  • seems redundant, removal? AsRef<T> could potentially be used instead.

• visit::IntoEdgeReferences

  • Proposal (6)

• visit::IntoEdges

  • Proposal (6)

• visit::IntoEdgesDirected

  • Proposal (6)

• visit::IntoNeighbors

  • Proposal (6)

• visit::IntoNeighborsDirected

  • Proposal (6)

• visit::IntoNodeIdentifiers

  • Proposal (6)

• visit::IntoNodeReferences

  • Proposal (6)

• visit::NodeCompactIndexable

  • Proposal: Trait Rework: GraphPrimitiveIndex #555

• visit::NodeCount

  • same as EdgeCount
  • Proposal: Trait Rework: Unify *Count into GraphLen #554

• visit::NodeIndexable

  • Proposal: Trait Rework: GraphPrimitiveIndex #555

• visit::NodeRef

  • Proposal (6)

• visit::VisitMap

  • Proposal: Trait Rework: VisitationMap #557

• visit::Visitable

  • Proposal: Trait Rework: VisitationMap #557

• visit::Walker

  • will land in petrgraph-algorithms instead.

• IntoWeightedEdge

  • part of (6), move to entry API

• Reversed

  • replace with implementations for std::cmp::Reverse?

Proposal

RFCs: #553, #554, #555, #556, #557, #558, #559

4. Elements

currently very confusing, no concrete proposal just yet.

6. Graph Iterators

TODO: This is where more experimentation is needed, after (1), this includes all iterators like IntoNeighbours, IntoNeighboursDirected, IntoEdges, IntoEdgesDirected, IntoNeighbours, IntoNeighboursDirected, IntoNodeIdentifiers, IntoNodeReferences. #469 has already done some research on the topic.

(Includes NodeRef and EdgeRef, potentially the should be structs instead of traits, renamed to NodeEntry and EdgeEntry and could support mutable access, would close #289 in a more generic way).

The goal is to unify as much as possible (while still retaining the ability to easily call them) and make them more robust.

Open Questions

• API breakage/deprecations (can we use crater to estimate "damage"?)
• Verify hypothesis: Only a minority of libraries/binaries use the traits directly; instead, they use the existing algorithms.
• What purpose has ElementIterator? It seems incomplete and prone to misuse/errors
  • This also includes Element
• Why does GraphRef exist?