Methods for `src` and `dest`

[CarloLucibello]

Since Graphs.jl owns the src and dest methods, it should provide specializations for tuples and pairs given the fact that they are commonly used to represent edges:

src(e::Union{Tuple, Pair}) = e[1]
dest(e::Union{Tuple, Pair}) = e[2]

[simonschoelly]

If you think you have a use case for that, then you probably could open a PR for that. Maye instead of dispatching on the general Tuple and Pair we can instead dispatch on Tuple{T, T, Vararg} where T and Pair{T, T} where T.

[CarloLucibello]

I was going to file a PR for this, then realized that it is not clear to me if the interface prescribes that an edge type has to be a subtype of AbstractEdge or not. For example, is it allowed for a custom graph type to have edges(g) return a generator yielding tuples?

This is not clear from this page https://juliagraphs.org/Graphs.jl/dev/ecosystem/interface/.

[jpfairbanks]

I’m inclined to say that your edge types should be subtypes of AbstractEdge. I don’t necessarily have documentation of primary communications to that effect, but that is my recollection of the decision making process there.

[simonschoelly]

I also would say it should still be a subtype of AbstractEdge. as it helps with dispatching. But some functions might still be able to accept tuples as an argument, where one would otherwise pass an edge.

[CarloLucibello]

ok, so maybe we shouldn't add those extra methods. I'll change my edges method in GraphNeuralNetworks.jl to return AbstractEdges.

It would be nice to lift this type restriction since it is used only sporadically in the library, but no big deal either.

I guess the actionable item here would be to clarify the docs.