There's no question about whether you should do such an horrible thing. You should definitely not, for all kinds of perfectly good reasons, like:
- Don't use sorted containers for unsorted data
- This is not how you use a comparer
- Avoid depending on implementation details of libraries you don't own
Now, to actually know whether you can preserve insertion order in a SortedList by hacking the comparer, there is only one way: look at the implementation. Decompile the bytecode, and see if it would work.
Turns out, SortedList
uses a binary search, and SortedDictionary
uses a red-black tree.
Fooling the binary search is easy. The comparer is only used for comparing new items (if you don't remove anything). Always return either 1 or -1, I always forget which, and you have an unsorted list.
For the red-black tree, I'm not sure whether the same trick works. I don't remember if that kind of tree has to use the comparer when it rebalances itself. If it does, the inability of your comparer to provide a meaningful result would lead you to runtime errors probably, or at best, loss of complexity guarantees. But maybe it's actually fine. Except that you will still get a maximum amount of rebalancing, I think.