Dominik Braun

Hi, thanks for your proposal and your questions! I'm happy to answer them. 1. At this point, `egdes` only exists for historical reasons. I decided to maintain an `outEdges` map...

Opened #13 for edge labels.

Making the store implementation flexible would be useful indeed. I think it might make sense to prescribe a store API and provide an in-memory default implementation like the current one...

So I took a look at your proposal and I like the design so far. I only have three thoughts or possible improvements in mind: 1. I'd love to default...

I see... Making `traits` generic comes with a huge overhead and won't be a viable solution. So there would be two possibilities: 1. Include the `Hash` function in `Store`, only...

Nice! Not needing the hashing function in `Store` makes things much simpler. To be honest, function calls like `graph.New(graph.IntHash, graph.Directed())` and `graph.NewWithStore(graph.IntHash, graph.InMemory(), graph.Directed()` are fine for me. That way,...

FYI: I've just merged PR #17 and released it as v0.5.0. This would need to be changed here as well.

I finally found a use case for the `edges` map, at least in the `undirected` graph: I'm planning to implement a `EdgesWithHashes` function that returns a `[]Edge[K]` (notice `K` instead...

Ah, I've waited with #25 because I thought this PR _and_ #25 would cause too many conflicts, but if you feel that #25 will simplify things here, we'll prioritize #25.

> @dominikbraun I assume that the plan for #25 is that all other graph methods will be using the new API right? In that case this PR will only have...