SList<T>

[arekbal]

Steep.SList<T> is meant to be a drop-in replacement for System.Generic.List<T>.

It is closest to working state out of all the classes now.

Most of original features should be possible to do one way or the other.
No point in leaving support for non-generic IList or ICollection.
Ignore inheritance.

Changes in API compared to original List<T> are desirable. For instance: ctor taking IEnumerable<T> will probably go away into static multiply overloaded Copy(...) ctor, and another MoveIn(T[]) might come in handy...).

Some obvious checks might be moved outside, to user space.

Rationale for having 'new' class (it is a struct now) replacing List<T> is how slow the original List<T> is:

• access by index meant copy.
• no Span access so no extra improvements.
• extra version variable dumpened enumerator.
• old enumerator means no ref on Current.
• no obvious extra enumerators such as Where or Select built in.
• Find, and so on, operate only on Predicate<T> which is slower then ref enabled equivalent.
• no point in extra self allocation(as object with class) if we could only have two fields now.

Some thoughts about futher improvements:

• There is a lot that can be done about non generic Array methods and extraneuos ifs.
• Already mentioned overloaded static ctors...
• More Enumerators...
• FilterToSList(...)
• With removes omit Array.Copy if plain swaps are more desirable(allow like 4 swaps???)
• Exchange Sort with IComparer into Sort<TComparer>(TComparer) where TComparer : IComparer for struct no-box comparers? same with IEnumerable<T> or ICollection<T>
• Sort with direction

So the plan is to reach the point where:

• we can demonstrate that it works - it is well tested.
• we are happy with the APIs.
• it is faster in every aspect than original List() by just doing less or doing stuff better, but often with less safe API.
• there is no low hanging fruit optimizations when we are done.
• we have examples showing the differences in API.