Things I’d Like to See, #766

I’d like a class derived from IEnumerable<T> to which it was possible to add an index.

Hear me out.  I have a project that involves generating and capturing a lot of data.  It’s not being retrieved from a database, and it’s not being saved to a database:  it’s being generated, analyzed, and ultimately discarded. 

While it lives, it lives in some collection classes, Lists and Lookups and the like.  While I’m analyzing it, I often have to summarize in multiple different ways, and do cross-verification and lookups by properties of the classes in the collections.  It’s (relatively) slow.  Any given lookup is, of course, lightning fast, but if it occurs over a big enough data set enough times, it gets slow.

Well, why not use a literal DataSet, then, you ask?  Those have indexes and primary keys and so on.  And that’s true.  But I want to preserve my strongly typed properties, and create derived (anonymous) summary types.  The syntax of doing that from a DataSet can get complex.  And as for typed DataSets, they have their value, but they’re tough to customize, even with the wonders that are partial classes.

Moreover, if I went the DataSet route, I’d need to define a DataTable for the result of every Linq summary class that I create, rather than using an anonymous type.  That does away with all the benefits of anonymous types, including the rather significant one that the compiler will adapt to any new fields I create in the source types (the ones being summarized), and either change the definition of the anonymous type or let me know I have a problem.  If I’m relying on DataTable that I create programmatically (or even with an XSD), I don’t find out I have a conflict in definitions until run time.  (Hopefully, test time, but once in a while something slips by you.) 

So:  I’d like a IEnumerable<T>-based type that supports adding indexes for performance purposes.