I want a tree collection

[zms9110750]

A regular multi branch tree would be fine. It can be used to load directory trees, subtrees of Jobjects, and object structures of Unity.
There is a built-in API that allows synchronization of others' implementations. For example, Jobject.
At the same time, I hope that DirectoryInfo can be implemented it.

Or, why isn't C # planning to build a tree collection?

[huoyaoyuan]

A generic tree model can be useful. Currently there are internal collections like ImmutableList<T> also using tree structures.
In many scenarios, the implementation detail of trees needs to be customized for optimization, so there should be interface as well.

@dotnet/area-system-collections thoughts? I can try to propose an API shape.

[eiriktsarpalis]

Is there a precedent for libraries exposing general-purpose tree types? It sounds like it would be a compromised design for most applications you would be trying to use it in. Modelling your own tree type is easy (especially with record types nowadays), why not just write your own that suits the requirements of your own application?

[AartBluestoke]

"tree" structures come in so many flavours - balanced, unbalanced, read/write/update optimised - what's the branching factor? can you branch on multiple keys? is the ability to find the smallest/largest important? is this a build once, or slowly growing tree? is memory or CPU performance more important?

I don't think the language can provide a solution without being quite un-optimal for many situations?

[frankhaugen]

For the runtime/BCL to have such a structure, it needs to clearly solve a problem that isn't trivial to solve in some random library. I recently had to make a Tree and it was a pain to work with, simply because asking questions of the data like "how many items are in an active state", or "find duplicates" got hard to answer when the depth was considerable. A way to wrap a hashset or something like it then present it as a tree, but its all references to the underlying "array-like" would maybe be something the team would contemplate doing.

But have a look at proposals and see how many are just closed, even if it has code attached. They're really conservative in adding features that have unclear business value, so getting this is probably achievable, but not quick nor easy

[danmoseley]

Not so much business value as does it need to be here.

Some considerations are

• does it need special runtime interactions (like Span)
• does anything else in the libraries need it - layering
• is it well defined what would be the right shape and behavior - not opinionated or fashionable
• does it compose well with other types, will it be useable and accessible and widely relevant to many or most apps
• is it platform table stakes based on being built in other platforms, usage we see, how often its reinvented, etc.
• is it worth not only the design and implementation time but also maintaining it for 10-20 years - we can almost never remove types
• will it be so stable it's OK if any features come only once a year

Often ideas are a better fit for a community project that can iterate faster and be opinionated.