feat: IndexedList and IIndexedList modules with the vocabulary of the FSharp.Core List module

[xperiandri]

Proposed Changes

Rewrites the legacy ImmutableList module as IndexedList (ImmutableList<'T>) and adds the interface module IIndexedList (IImmutableList<'T>) after ADR 0001 (#23). It builds on #26 (FlatList), which is merged into main.

• Layout (D2): IndexedList, IIndexedList, their Option and Tuple modules and IndexedListBuilder are the root modules of their files, such as module FSharp.Collections.Immutable.IndexedList. The IndexedList<'T> abbreviation lives in IndexedList/IndexedListTypes.fs, which needs no signature file.
  • Every other file with public bindings has a signature file that carries its XML documentation, compiled right before it: IndexedListBuilder.fsi and IndexedListCE.fsi included.
  • indexedList has its val in ComputationExpressions.fsi, after flatList under the Creation banner.
• IndexedList/IndexedList.fsi and IndexedList.fs: 162 functions, in the canonical category order. They are the IndexedList column of ADR Appendix A, with exactly the parameter names of the FSharp.Core List module, so the exceptions name the same parameters as List.
  • The members of ImmutableList come first (D5): ConvertAll, FindAll, FindIndex, FindLastIndex, TrueForAll, Exists, GetRange, Insert, InsertRange, RemoveAt, RemoveRange, SetItem, IndexOf, LastIndexOf, BinarySearch, and now Remove, RemoveRange (items), Replace and Reverse (index, count).
  • Everything else copies to an array, calls the Array function and builds a balanced tree with ImmutableList.CreateRange.
  • rev takes the faster path that the maintainer chose over ImmutableList.Reverse (D5). It copies the elements to an array, reverses it with Array.Reverse and builds the result with ImmutableList.CreateRange. At 100 000 integers it takes about 3 ms where ImmutableList.Reverse, which the 1.0.0 reverse called, takes about 23 ms (about 8 times faster; 40 ms against 265 ms at 1 000 000), and it allocates 5.2 MB where Reverse allocates 4.8 MB, because of the copy of the elements. The numbers are the median of 15 rounds in Release on .NET 10, for a list from CreateRange and for one built with Add, run on the 1.0.0 assembly and on this branch.
  • Every sort is stable, as List.sort* is. ImmutableList.Sort is unstable, so it is not used.
    • sort and sortWith sort with the FSharp.Core Seq sorts, which share the stable sort of List: they make the same comparisons, in the same Array.Sort.
    • sortDescending and sortByDescending call Seq.sortWith through the internal DescendingSorts module (Helper/DescendingSorts.fs), with the cached comparer reversed. Seq.sortDescending and Seq.sortByDescending are inline: inside a generic function they compare with the generic operator, which boxes the elements, or the keys, in every comparison and allocates 7.5 MB at 10 000 integers. The comparisons, their order and the exceptions stay those of List; only the boxes go.
    • sortBy and sortWithComparer sort with LINQ OrderBy/Order, which compute the keys first, as List.sortBy does.
    • sortRange, sortRangeWith and sortRangeWithComparer sort a copy of the range with LINQ Order and put it back with RemoveRange and InsertRange, so they are stable too. ImmutableList.Sort (index, count, comparer) is unstable and copies the whole list.
  • The sorts and binarySearch compare with the cached DefaultComparer<'T>.Instance of feat: FlatList module with the vocabulary of the FSharp.Core Array module #26, so a call does not create a comparer.
  • The extras are add, cons, uncons, tryUncons, tryTail, skipLast, takeLast, build, update, blit, binarySearch, indexOf/indexOfWith/lastIndexOf/lastIndexOfWith, sortWithComparer, the span constructors and the Cons/Nil patterns.
  • Functions that wrap more members of ImmutableList, from the API gap analysis of the modules (20 functions):
    • Removal and replacement by value, in EqualityComparer<'T>.Default or a given equality comparer: remove, removeWith, removeMany, removeManyWith, replace, replaceWith. Nothing to remove returns the input itself, and replace throws ArgumentException for a value that no element equals, as the BCL does.
    • The range: sub (it throws what Array.sub throws, as FlatList.sub does), revRange, indexOfRange, indexOfRangeWith, lastIndexOfRange, lastIndexOfRangeWith, tryFindIndexRange and tryFindIndexBackRange. The searches return indices of the whole indexed list.
    • Binary searches with a comparer, binarySearchWithComparer, binarySearchRange and binarySearchRangeWithComparer, and the stable sortRange*.
• IIndexedList.fsi and IIndexedList.fs: 136 functions over IImmutableList<'T>.
  • Results of the same element type keep the implementation of the input: Clear () plus AddRange, or the member of the interface for an edit of one element. rev reverses its copy in place, as IndexedList.rev does, before it rebuilds.
  • Results of another element type are an IndexedList. So are concat and transpose, because their inputs can have different implementations.
  • The sorts are the same as in IndexedList.
  • remove, removeWith, removeMany, removeManyWith, replace and replaceWith call the members of the interface, so they keep the implementation too. The four searches in a range call the members of the interface after the module has checked the range.
  • A test with a custom IImmutableList implementation proves that the module keeps it.
• Exceptions (D6, D14): every function throws what the FSharp.Core List function throws: the type, the message and the parameter name. This includes the quirks of List:
  • The functions of two and three lists call their callback on the common prefix before they throw.
  • exists2 and forall2 can return before they check the lengths.
  • removeManyAt removes nothing for a count that is not positive, and nothing when index + count overflows, because List walks the first index + count elements. The Copilot review found the overflow: such a range used to reach RemoveRange, which threw.
  • A comparison or a projection that throws in sort, sortDescending, sortWith or sortByDescending throws an InvalidOperationException with the original exception inside, as Array.Sort does in List. List.sortByDescending calls the projection in the comparison, and so does this module now. sortBy lets an exception of the projection escape, as List.sortBy does.
  • List reports some unusual parameter names, and the module reports them too: "source" for exactlyOne, average and averageBy; "count" for init; "list.[j]" for transpose.
  • A null input throws ArgumentNullException.
  • A parameter of type seq<'T> rejects null and a default flat list given as a sequence, a boxed struct that fails with InvalidOperationException as soon as the BCL enumerates it, with ArgumentNullException that names the parameter of the function. checkNotNullOrDefaultSeq does it in IndexedList (ofSeq, concat, insertManyAt, removeMany, removeManyWith, transpose, except), in IIndexedList (the same functions but ofSeq; concat and transpose reject a default flat list as an element too, because it implements IImmutableList<'T>), in IndexedListBuilder (addRange, insertManyAt, removeMany, removeManyWith) and in indexedList { } (yield! of a sequence and for). The Option and Tuple modules have no sequence parameter.
  • The functions that wrap a member of ImmutableList that List lacks throw what the member throws, with the names of their own parameters (D6). Where the member contradicts its own documentation or answers with a wrong index, the module follows the documentation (D14). The internal module ListRanges (Helper/ListRanges.fs) checks the ranges first, comparing the count with the difference between the length and the index:
    • The members add the index and the count, which wraps around Int32.MaxValue: IndexOf (item, Int32.MaxValue, 1) returns -1, and Reverse (Int32.MaxValue, 1) returns the list, for a list of five elements. The module throws ArgumentOutOfRangeException.
    • BinarySearch (index, count, item, comparer) does not check that the range lies in the list, although its documentation promises ArgumentException. binarySearchRange* throws ArgumentException.
    • LastIndexOf and FindLastIndex accept a last element at or after the end of the list and answer with the index of another element: LastIndexOf (20, 5, 2) on [10; 20; 30; 20; 10] returns 4, and element 4 is 10. FindLastIndex also takes a negative count for "all". lastIndexOfRange* and tryFindIndexBackRange throw ArgumentOutOfRangeException, also where LastIndexOf throws a plain ArgumentException.
• Option and Tuple namespaces: the IndexedList and IIndexedList modules repeat the functions with voption or struct tuples (D3). Option.IndexedList has tryFindIndexRange and tryFindIndexBackRange too.
• Builder and computation expression (D7): IndexedListBuilder works on ImmutableList<'T>.Builder (37 functions), and its sorts are stable too. It gets insertManyAt, removeAll, removeMany, removeManyAt, removeManyWith, removeWith, replace, replaceWith, revRange, sortRange*, the four searches in a range, binarySearch, binarySearchWithComparer, binarySearchRangeWithComparer and blit. replace throws ArgumentException for a value that no element equals, as the builder of the BCL does, and addRange names values in its ArgumentNullException, where the BCL names items. indexedList { } builds an indexed list. yield! of a null sequence, array or indexed list throws ArgumentNullException for items.
• Helper/ gets a shared List layer that Queue and Stack will reuse, one root module per file:
  • ListChecks holds the checks of the List functions, with their exact exceptions.
  • ListArrays holds the two- and three-collection algorithms with the behaviour of List.
  • Snapshot copies a sequence to an array.
  • DescendingSorts holds sortDescending and sortByDescending: the stable sorts of List without the boxes of the inline Seq sorts, for the descending sorts of Queue, Stack and their interface modules too.
  • Lengths counts a queue or a stack only up to a limit, for the checks that tell an empty input, one element and more apart. queueUpTo reads IsEmpty and calls Dequeue at most limit − 1 times; stackUpTo pops without an allocation. No function of this pull request calls it, so the tests of Queue and Stack will cover it.
  • ListRanges holds the checks of the functions that take a range of an indexed list or of its builder: forward, backward, search and blit. IndexedList.blit uses it too.
  • Raise.fs gets invalidArg2ListsDifferent, invalidArgRandomizerOutOfRange and invalidOpListEmpty, written with interpolated strings like the rest of the module. The message that the index functions of List (insertAt, insertManyAt, removeAt, removeManyAt and updateAt) write as a literal is in no resource, so it is a private literal of ListChecks and not a constant of ErrorStrings.
• Changelog: the new functions are listed, and the Added, Changed and Removed entries compare with the published 1.0.0 assembly, where the list module is ImmutableListModule with 75 functions and IndexedSeq has 3. They were checked by reflection, by compiling against the assembly and by running its functions next to the new ones, not against main.
  • Removed names the 23 functions that 1.0.0 had and IndexedList lacks, each with its replacement. Thirteen are renames with the same arguments, in one entry: lastIndex, lastIndexWith, indexRange, indexRangeWith, lastIndexRange, lastIndexRangeWith, insert, insertRange, removeRange, exceptWith, reverse, reverseRange and withItem. The other ten are index, indexWith, indexFrom and indexFromWith (they returned a function that took the list a second time), lastIndexFrom and lastIndexFromWith (with the formulas), clear, skipUntil, takeUntil and filterFold (no replacement). The IndexedSeq module (check, item, length) and the IIndexedSeq<'T> abbreviation are listed with IReadOnlyList<'T> as the replacement.
  • Added no longer names what 1.0.0 had: add, cons, remove, removeWith, replace, replaceWith and tryTail.
  • Changed names what running both showed. The module is compiled as IndexedList with PascalCase names, where ImmutableListModule had the F# names. The functions take ImmutableList<'T>, where 1.0.0 took any IImmutableList<'T>; ofList, collect, concat and append take indexed lists or an F# list, where they took any sequences. tryFind, tryFindIndex, tryHead, tryItem, tryLast and tryTail return voption. head, last, tail, item, removeAt, take, skip, truncate, splitAt, forall2, contains and ofBuilder throw other exceptions or return other results. skipWhile and takeWhile do what their names say, except follows List.except, and the equality of contains, remove, replace and the indexOf family differs. rev is faster.
  • The Removed entry of the IndexedSeq module does not list the ReadOnlyList alias of 1.0.0: a module abbreviation cannot be used from another assembly. A project that references the 1.0.0 package compiles IndexedSeq.length and IIndexedSeq<int>, and does not compile ReadOnlyList.length.
• Removed files: the legacy ImmutableList.fs and IndexedSeq.fs. docsSrc/Tutorials/Getting_Started.md no longer calls the removed ImmutableList.ofSeq.

Tests: 7832 per target framework, 5072 of them new (main has 2760).

• The tests compare arrays and take their cases as DataRow and DynamicData rows, so every case runs and reports as a test of its own.
  • The case tables are maps whose names are the rows.
  • Lists remain only as the oracles of the List functions where Array behaves differently (the stable sorts, the walk of the common prefix, exists2/forall2, removeManyAt, the exceptions) and as the list case of yield!.
• IndexedList derives the sequence-like, creation, index-based and stable-sort contracts.
• IIndexedList derives the sequence-like, index-based and stable-sort contracts, over indexed lists upcast to the interface.
• Contracts/StableSortContract.fs is new.
  • It checks that every sort* keeps the order of equal keys, on the 20 pairs of the new Inputs.ManyPairs, whose keys repeat. The sort of .NET orders up to 16 elements by insertion, which keeps equal keys in order. As the Copilot review noted, the six Inputs.Pairs therefore could not tell a stable sort from an unstable one.
  • With every sort switched to the unstable algorithm of ImmutableList.Sort for a moment, the 12 stable-sort contract tests and the stability test of the builder sorts fail.
  • It checks that a comparison that throws (sort, sortDescending, sortWith) and a projection that throws (sortBy, sortByDescending) throw what List throws, as the review of feat: Queue and IQueue modules with the vocabulary of the FSharp.Core List module #33 asked, and that sortByDescending calls the projection in the comparisons, in the same order, as List.sortByDescending does.
  • It checks that sortDescending and sortByDescending allocate less than 3 MB for 10 000 integers: 1.2 MB with DescendingSorts, 8 MB with the inline Seq sorts, in Debug and in Release. With the inline sorts back, exactly these four tests fail.
• IndexedList/ListMembersContract.fs is new. IndexedList and IIndexedList derive it, and no other module has these functions, which is why it is not part of the shared contracts that FlatList and the queues run.
  • It checks the removal and the replacement by value, in the default equality and with a comparer that ignores the case, on strings; the input itself when nothing is removed; the exception and the parameter of replace; the four searches in every range of eight strings; and the exception of every range that is rejected, with the ranges that the members of ImmutableList accept (D14).
  • IndexedList/ListMemberCases.fs is new too. It holds the strings and the rows that the contract, IndexedListRangeTests and IndexedListBuilderTests share, and the oracles that feat: FlatList module with the vocabulary of the FSharp.Core Array module #26 does not have: the change of a range, the stable sort, the removal of several values and the search from the back.
  • Both files come after FlatList/FlatListOracles.fs of feat: FlatList module with the vocabulary of the FSharp.Core Array module #26 and use its removeFirst, replaceFirst, firstInRange, equalIgnoringCase, descending and byAbsolute. The tests of null inputs call FlatListAssert.RejectsNull of feat: FlatList module with the vocabulary of the FSharp.Core Array module #26 too. The oracle of the search from the back answers -1 for a range of no elements before it calls lastInRange, because the bounds of a range that starts at Int32.MaxValue overflow, and the members of ImmutableList accept such a start index for an empty range.
• IndexedListRangeTests covers sub, revRange, sortRange*, the binary searches and tryFindIndexRange/tryFindIndexBackRange: every range of the inputs against the arrays, the stability of the range sorts on Inputs.ManyPairs, and the parameter that each function names for a range that it rejects. Its rows of the ranges are the ones of FlatListTests.
• The sequence inputs are in the shared contracts wherever every implementer has the function, so FlatList runs them too and the queues and the stacks will:
  • SeqCreationContract: ofSeq rejects a default flat list given as a sequence with what it throws for a null sequence.
  • SeqLikeTransformationContract: concat and transpose, one data-row test each, reject a null sequence of collections with ArgumentNullException that names the parameter of FSharp.Core (arrays or lists, mapped to the name of the module), and reject a default flat list with what they throw for a null one. List.concat throws NullReferenceException for null, so the test asserts the exception of the module.
  • SeqLikePartitioningContract: except rejects a default flat list given as the items to exclude like null items, also for an empty input.
  • IndexedContract: insertManyAt rejects null values and a default flat list with ArgumentNullException for values, and checks the index before the values.
  • ListMembersContract (IndexedList and IIndexedList): removeMany and removeManyWith reject null items and a default flat list, on an empty and on a non-empty collection, and check the collection before the items. The tables of each module add what a contract over integers cannot say: a default flat list of strings given as a sequence of objects, the order of the checks, a default flat list as an element, and yield! and for of the expression. Inputs.DefaultFlatListAsSeq is the one small addition to the contracts of chore: lay the foundation for the per-collection modules #25.
• Shared contracts, without weakening them for FlatList:
  • The null array case of ofArray uses Array.toList as its List reference, because List.ofArray throws NullReferenceException.
  • removeManyAt with a count that is not positive moved to its own test, and a new test covers ranges whose end overflows Int32.MaxValue. Both expect exactly what the mirrored function does: its result or its exception.
• Categories are on the test classes only (D8): the collection and the area that a class examines. The classes with the tests of the Cons and Nil patterns also carry PatternMatchingTestCategory.
• IndexedListOps and IIndexedListOps are the root modules of their own files.
• The per-collection tests cover null inputs of every function, shared trees, cons/uncons and the patterns, binarySearch, blit, the builder, the computation expression, yield! of null and both namespaces.
• Breaking each new behaviour once, in a copy of the sources (81 changes: a call dropped, a comparer ignored, the arguments swapped, a check removed, the stable sort replaced by the BCL sort, the range check replaced by the sum of the index and the count), fails the tests in every case that changes a result: 78 of the 81 changes. The other three change no result:
  • an additional check in IndexedList.blit, which the function makes anyway (a control that has to stay green);
  • IndexedListBuilder.sortRange* that sorts a range of one element instead of skipping it, which leaves the builder as it was;
  • ListRanges.search without the check of a negative count, which BinarySearch makes again and answers with the same exception.
• Breaking each fix of the sequence inputs once (28 changes: the check back to a null check, the check removed, the checks in the old order, the check of an element removed) fails the tests in every case.

Types of changes

What types of changes does your code introduce to FSharp.Collections.Immutable?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

These changes break existing code:

• ImmutableList is renamed to IndexedList.
• The try* functions return voption, and tuples are struct tuples.
• skipWhile and takeWhile return what their names say. In 1.0.0 each of them returned the result of the other one.
• The IndexedSeq module and the legacy functions in the Removed section of the changelog are gone.

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• Build and tests pass locally
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Further comments

• Checked against 1.0.0: running the published assembly next to this branch showed, besides the differences in the changelog, that the 1.0.0 skipWhile, takeWhile, skipUntil and takeUntil returned each other's results; that index, indexWith, indexFrom and indexFromWith returned a function that took the list a second time; that lastIndexRange accepted a start index at the end of the list and answered with an index that the list does not have, and lastIndex of an empty list threw; and that forall2 returned true for lists of different lengths when the common pairs satisfied the predicate.
• LINQ and the exceptions of a sort: LINQ Order already wraps the exception of a comparison in InvalidOperationException, as Array.Sort does. With the old LINQ sorts, only the sortByDescending test fails, because OrderByDescending computes the keys before it sorts. The four sorts moved to Seq anyway: they now make exactly the comparisons that List makes.
• Cost of the Seq sorts: the inline Seq.sortDescending and Seq.sortByDescending boxed every integer in every comparison; the work on Queue found it. The numbers are those of the library itself, in Release on .NET 10 with FSharp.Core 10.1.301, for 10 000 integers with 1000 distinct values: the median of eight rounds of 100 calls, run alternately before and after the fix, and the best single call in brackets.
  • IndexedList.sortDescending took 7.22 ms (3.46 ms) and allocated 7 508 744 bytes per call. It takes 1.67 ms (0.90 ms) and allocates 680 336 bytes.
  • IndexedList.sortByDescending by the integer itself took 7.64 ms (3.74 ms) and allocated 7 508 768 bytes. It takes 2.20 ms (1.11 ms) and allocates 680 344 bytes.
  • IIndexedList.sortDescending and sortByDescending took 7.20 ms and 7.96 ms with the same allocation, and take 1.68 ms and 2.04 ms.
  • The other sorts do not change: sortWith takes 1.76 ms (0.82 ms) and allocates 680 312 bytes, sort 0.80 ms and 560 208 bytes, sortBy 1.40 ms and 640 416 bytes, sortWithComparer 0.73 ms and 520 104 bytes. Most of the allocation is the tree of 10 000 nodes and the arrays of the sort.
• Boxes that remain: sort and sortDescending of a value type without a primitive comparer, such as struct (int * int), allocate 17 MB for 10 000 elements. F# comparison boxes such a value in every comparison, and FSharp.Core does so in List.sort (17.2 MB), Seq.sort and Array.sort (15.3 MB) too; the cached comparer is that comparison. Integers and strings do not box.
• Cost of the range functions: the numbers are those of the library, in Release on .NET 10, as the median of 9 to 31 runs after a warm-up, for integers.
  • The cost of a range depends on its length, not on the length of the list. sub list (n / 2) 1000 takes 80 µs, 93 µs and 69 µs for n = 10 000, 100 000 and 1 000 000, and allocates 48 024 bytes each time. IndexedList.skip followed by take takes 0.59 ms, 5.5 ms and 56 ms and allocates 0.29 MB, 2.4 MB and 24 MB, because each of them builds a tree.
  • sortRange (n / 2) 1000 takes 0.23 ms, 0.27 ms and 0.27 ms for the same three lengths, and sorting 1 000, 10 000 and 100 000 elements of a list of 1 000 000 takes 0.27 ms, 4.0 ms and 35 ms. The BCL Sort (400 000, 10 000, comparer) takes 68 ms and allocates 52 MB, because it copies the whole list into an array and builds a new tree; sortRange takes 2.3 ms and allocates 1.6 MB. The alternatives that copy the range into an array (2.3 ms, 1.0 MB) or write the sorted elements through a builder (3.5 ms, 1.0 MB) are not faster, so the plan of GetRange, Order, RemoveRange and InsertRange stays.
  • revRange (n / 2) 1000 takes 0.13 ms, 0.25 ms and 0.25 ms; reversing 1 000, 10 000 and 100 000 elements of a list of 1 000 000 takes 0.26 ms, 2.9 ms and 27 ms.
  • indexOfRange at the end of a list: 1 000 elements take 25 µs, 27 µs and 15 µs for the same three lengths, and 100 000 elements of a list of 1 000 000 take 1.5 ms (lastIndexOfRange: 1.1 ms). The work depends on the length of the range, as the O(log n + count) of the documentation says.
• Decisions for the maintainers:
  • The module throws ArgumentOutOfRangeException where LastIndexOf throws a plain ArgumentException, because the first is an ArgumentException too and it names the parameter. binarySearchRange* throws a plain ArgumentException for a range beyond the end, as the documentation of BinarySearch says.
  • The throwing pair findIndexRange and findIndexBackRange is not added; the analysis calls it optional.
  • IndexedListBuilder has binarySearchRangeWithComparer only, as the analysis proposes; binarySearchRange of IndexedList is the same call with the default comparer.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Overflowing removal ranges violate the promised List behavior, and stability tests need stronger regression inputs.

2 open issues

• Handle count overflow in removeManyAt no-op validation · New
• Add larger duplicate-key fixtures to detect unstable sorting · New

What changed in this PR

Replaces the legacy immutable-list API with IndexedList and IIndexedList, continuing ADR 0001’s per-collection rewrite.

Changes:

• Adds List-compatible operations, stable sorting, and implementation-preserving interface operations.
• Adds Option/Tuple variants, builder helpers, and indexedList { }.
• Expands contract tests and updates migration documentation.

File	Description
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListTupleTests.fs	Tests reference-tuple overrides.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListTests.fs	Tests concrete-list semantics and extras.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListOptionTests.fs	Tests option overrides.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListOps.fs	Connects both modules to contracts.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListContractTests.fs	Instantiates shared contracts.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListComputationExpressionTests.fs	Tests computation expressions.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IndexedListBuilderTests.fs	Tests builder operations and stability.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IIndexedListTupleTests.fs	Tests interface tuple overrides.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IIndexedListTests.fs	Tests implementation preservation and validation.
tests/​FSharp.Collections.Immutable.Tests/​IndexedList/​IIndexedListOptionTests.fs	Tests interface option overrides.
tests/​FSharp.Collections.Immutable.Tests/​FSharp.Collections.Immutable.Tests.fsproj	Includes new test files.
tests/​FSharp.Collections.Immutable.Tests/​Contracts/​StableSortContract.fs	Adds shared stability checks.
tests/​FSharp.Collections.Immutable.Tests/​Contracts/​SeqCreationContract.fs	Adjusts null-array expectations.
tests/​FSharp.Collections.Immutable.Tests/​Contracts/​IndexedContract.fs	Covers nonpositive removal counts.
src/​FSharp.Collections.Immutable/​IndexedSeq.fs	Removes legacy indexed-sequence bindings.
src/​FSharp.Collections.Immutable/​IndexedList/​IndexedListTuple.fsi	Declares tuple overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IndexedListTuple.fs	Implements tuple overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IndexedListOption.fsi	Declares option overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IndexedListOption.fs	Implements option overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IndexedListCE.fs	Implements the computation-expression builder.
src/​FSharp.Collections.Immutable/​IndexedList/​IndexedListBuilder.fs	Adds mutable builder helpers.
src/​FSharp.Collections.Immutable/​IndexedList/​IIndexedListTuple.fsi	Declares interface tuple overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IIndexedListTuple.fs	Implements interface tuple overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IIndexedListOption.fsi	Declares interface option overrides.
src/​FSharp.Collections.Immutable/​IndexedList/​IIndexedListOption.fs	Implements interface option overrides.
src/​FSharp.Collections.Immutable/​ImmutableList.fs	Removes the legacy module.
src/​FSharp.Collections.Immutable/​Helper.fs	Adds shared List checks and algorithms.
src/​FSharp.Collections.Immutable/​FSharp.Collections.Immutable.fsproj	Registers replacement modules.
src/​FSharp.Collections.Immutable/​ComputationExpressions.fs	Exposes indexedList.
README.md	Updates the collection catalog.
docsSrc/​Tutorials/​Getting_Started.md	Migrates the list-construction example.
docsSrc/​index.md	Updates the collection catalog.
docsSrc/​Explanations/​Background.md	Updates supported collection bindings.
CHANGELOG.md	Records additions and breaking changes.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The broad breaking API migration and exact List-compatibility requirements need human validation across both target frameworks.

No open issues 🎉

2 resolved since last review

• Handle count overflow in removeManyAt no-op validation
• Add larger duplicate-key fixtures to detect unstable sorting

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The broad breaking API migration and exact FSharp.Core compatibility guarantees require final human validation.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The broad breaking API migration and exact FSharp.Core compatibility requirements warrant final human validation.

No open issues 🎉

_{Review effort: Balanced}

[xperiandri]

Have you compared to non-snapshot implementations?

[xperiandri]

why not builder?

[xperiandri]

is it the most optimal implementation?

[xperiandri]

why not builder?

[xperiandri]

looks stupid

[xperiandri]

what about IIndexedList interface alias?

[xperiandri]

use WantSome for all such cases in all tests