Accept Nullable element types in the ordered containers without a comparer

[matt-edmondson]

Fixes #71

When no comparer is passed, the constructors of OrderedSet<T>, OrderedCollection<T> and OrderedMap<TKey,TValue> required the type itself to implement IComparable<T> or IComparable. Nullable<U> implements neither, so new OrderedSet<int?>() threw ArgumentException, even though Comparer<int?>.Default orders nullable values with null first.

Change

• Added an internal helper, Comparability.HasDefaultOrdering<T>(). It keeps the old check, and when the type is Nullable<U> it falls back to checking U.
• Replaced all eight copies of the old check with the helper. That covers every no-comparer constructor of the three containers, including OrderedMap's primary-constructor field initializer.
• A nullable wrapper around a type that is not comparable, such as KeyValuePair<int,int>?, is still rejected.

OrderedMap keeps its where TKey : notnull constraint, the same one Dictionary has. OrderedMap<int?, …> therefore still produces compiler warning CS8714, and null keys are still rejected at run time. The difference is that construction and ordering no longer fail.

Tests

• For all three containers there are new tests that construct int? instances through the parameterless, capacity and collection constructors and check that the order matches Comparer<int?>.Default, with null first for the set and the collection.
• There are also guard tests that the KeyValuePair<int,int>? case still throws.
• I reverted the source changes and ran the tests again: the three construction tests fail. With the change they pass.
• The full Containers.Test suite passes (395/395), and the Release build has no warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXTjHR3MfJpmxt8LEwNkjm

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
91.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud