Skip to content

fix: let OrderedCollection.GetRange take a zero-length range at the end [patch] - #60

Merged
matt-edmondson merged 1 commit into
mainfrom
claude/containers-59-getrange-zero-length-at-end
Sep 24, 2026
Merged

matt-edmondson merged 1 commit into
mainfrom
claude/containers-59-getrange-zero-length-at-end

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

Fixes #59.

OrderedCollection<T>.GetRange guarded startIndex with ThrowIfGreaterThanOrEqual(startIndex, Count), which rejects startIndex == Count. That made a zero-length range at the end of the collection impossible to request, and made GetRange unusable on an empty collection at all — even though count == 0 makes both requests perfectly valid:

new OrderedCollection<int>().GetRange(0, 0);    // threw ArgumentOutOfRangeException
collection.GetRange(collection.Count, 0);        // threw for any collection

List<T>.GetRange explicitly allows index == Count when count == 0, and the sibling collections in this repo already agree — InsertionOrderCollection.GetRange and ContiguousCollection.GetRange both check only startIndex >= 0, count >= 0 and startIndex + count <= Count. OrderedCollection was the only one carrying the extra check, so this is as much a consistency fix as a correctness one.

The change

The one line is dropped. The remaining three guards still reject every genuinely out-of-range request, which is worth spelling out because it is the reason no narrowing comes with this:

  • startIndex negative → ThrowIfNegative(startIndex)
  • count negative → ThrowIfNegative(count)
  • past the end, e.g. GetRange(3, 1) on a 3-element collection → startIndex + count > Count

That last one is what the existing GetRange_InvalidStartIndex_ThrowsArgumentOutOfRangeException asserts, and it still passes unmodified: the removed check was redundant for every case except the valid one it was rejecting.

The XML doc gains a <remarks> noting the List<T> parity, since the boundary is now part of the method's contract.

Tests

Three added next to the existing GetRange_ValidRange_ReturnsCorrectSubset, which only covered a mid-collection range. Verified by stashing the OrderedCollection.cs change and re-running:

Test Without the fix
GetRange_ZeroCountAtEnd_ReturnsEmpty fails — startIndex ('3') must be less than '3'
GetRange_ZeroCountOnEmptyCollection_ReturnsEmpty fails — startIndex ('0') must be less than '0'
GetRange_ZeroCountMidCollection_ReturnsEmpty passes — a regression guard for the zero-count case that already worked, not a failing-first test

Full suite: 373 passed, 0 failed, 0 skipped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01T1ntzPwg732TrH7D5vWpSV


Generated by Claude Code

…nd [patch]

GetRange guarded startIndex with ThrowIfGreaterThanOrEqual(startIndex, Count),
which rejects startIndex == Count. That made a zero-length range at the end of
the collection impossible to request, and made GetRange unusable on an empty
collection at all, even though count == 0 makes both requests valid.

List<T>.GetRange explicitly allows index == Count when count == 0, and the
sibling collections in this repo already agree: InsertionOrderCollection and
ContiguousCollection check only startIndex >= 0, count >= 0 and
startIndex + count <= Count. OrderedCollection was the only one with the extra
check.

Drop it and rely on the remaining three guards, which still reject every
genuinely out-of-range request - including GetRange(3, 1) on a 3-element
collection, via startIndex + count > Count.

Adds three tests. Two fail before the change:
- GetRange_ZeroCountAtEnd_ReturnsEmpty
- GetRange_ZeroCountOnEmptyCollection_ReturnsEmpty
and GetRange_ZeroCountMidCollection_ReturnsEmpty guards the case that already
worked.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T1ntzPwg732TrH7D5vWpSV
@sonarqubecloud

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit 7ea4137 into main Sep 24, 2026
12 checks passed
@matt-edmondson
matt-edmondson deleted the claude/containers-59-getrange-zero-length-at-end branch September 24, 2026 00:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OrderedCollection&lt;T&gt;.GetRange rejects a valid zero-length range at the end of the collection

2 participants