Graphs logic

[DashNY]

Do you have any plans to add logic for manipulating generic graph structures? E.g. adding nodes, vertices, depth/breadth-first searches, traversal algorithms, cycle detection, etc.
Thank you.

[ianhays]

There's nothing on the docket, but you're more than welcome to submit an API Proposal if you have something in mind.

[pgolebiowski]

• Although up-for-grabs means Small sections of work which we believe are well scoped., I think this is pretty ambiguous (potentially huge) and the scope needs to be defined.
• This is pretty advanced and it will not be used that often as for example a priority queue https://github.com/dotnet/corefx/issues/574, where we didn't want to even have an interface to make a common core for extension...
• However, if we have an assumption that this is something we wish to have, I would absolutely love to work on this one!! ❤️ 😄

@ianhays @safern @karelz -- what are your opinions?

[karelz]

Although up-for-grabs means Small sections of work which we believe are well scoped., I think this is pretty ambiguous (potentially huge) and the scope needs to be defined.

Agreed. We used api-needs-work + up-for-grabs in a way to express "we do not plan to make the API proposal". It was my idea. It was a bad idea in retrospective.
It is on my list to clean up during June/July and change the triage rules a bit. Also brewing in my head for last few weeks.
I plan to resolve it together with plan for updates to simple' / up-for-grabs' meanings -- there are 3 categories IMO first-timer-only, simple work to start in repo, involved work we would welcome help with.
We discussed it at .NET Fringe conference with few other OSS maintainers and we plan to ask authors of up-for-grabs.net for blessing/permissions to make changes to the site in that manner (@daveaglick mentioned such idea was rejected by the owners in the past, so we might hit a hard wall).
However, we believe there is OSS-wide desire for something like that, not tied to CoreFX or .NET.

[karelz]

Regarding this particular issue. I strongly believe it is way beyond the scope of CoreFX. It would be definitely great to have great graph library for .NET, but it does not belong into CoreFX. It might be a decent fit for CoreFXExtensions repo with PowerCollections, etc.
The best outcome would be if there was community driven effort for such libraries, as .NET team won't scale to govern all of such APIs. We can provide guidance on API reviews, but we can't scale to own and be responsible for all such code. Anyway, something to think about over the summer and find a solution for.

Removing up-for-grabs here.

[karelz]

OK, I created the uber-"out of scope" issue now. It will be easier. Graphs are tracked in dotnet/corefx#20902.
If someone wants to argue that it should be in scope, let's continue the discussion here.

Closing for now, until there is strong (multiple contributors) push back against the "out of scope" decision.

[daveaglick]

FWIW, Microsoft actually already has a good graph library called MSAGL (formerly GLEE): https://github.com/Microsoft/automatic-graph-layout

It's geared partly towards visualization and layout, but the underlying structures are quite good and could be extended for various traversal and other algorithms. Worth a check to see if it meets your requirements (don't be put off by the emphasis on WPF - everything under the hood is GUI agnostic).

[karelz]

Thanks @daveaglick, note & link added to the top post of dotnet/corefx#20902.