You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[API Proposal]: System.Collection.BitArray - New constructors to pass a ReadOnlySpan<T> where T is int, bool or byte #80263
The System.Collection.BitArray has a constructor that accepts an array of boolean, byte or int.
As we now have ReadOnlySpan<byte>, ReadOnlySpan<bool> and ReadOnlySpan<int>, that would be great to add three new constructors to accept these span.
Currently we must do a ".ToArray" on the span.
API Proposal
namespaceSystem.Collections;publicsealedclassBitArray:ICollection,ICloneable// So, the existing one{publicBitArray(ReadOnlySpan<byte>bytes);publicBitArray(ReadOnlySpan<bool>values);publicBitArray(ReadOnlySpan<int>values);}
(Sorry for the typo.)
Yes, it should be 96, 3 and 24.
In fact it must follow the same behaviour as the existing ones with array (int[], bool[], byte[]).
My request here is just to avoid an unnecessary "ToArray()" on the span.
With the increased adoption of Span across the BCL, avoiding intermediate allocations has become a common expectation rather than a micro-optimization.
BitArray currently requires calling .ToArray() when working with spans, which introduces an unnecessary allocation despite the type already copying internally.
Given the low implementation cost and consistency with modern APIs, it might be worth reconsidering either:
span-based constructors, or
a static factory method (Create(ReadOnlySpan)) to limit API surface growth.
Activity
DrkWzrd commentedon Jan 5, 2023
array1should have 96 bits;array23 bits and array3 (there's a typo in the example)24 bits, isn't it?jimmygilles commentedon Jan 5, 2023
(Sorry for the typo.)
Yes, it should be 96, 3 and 24.
In fact it must follow the same behaviour as the existing ones with array (int[], bool[], byte[]).
My request here is just to avoid an unnecessary "ToArray()" on the span.
thomasnalix commentedon Apr 18, 2026
With the increased adoption of Span across the BCL, avoiding intermediate allocations has become a common expectation rather than a micro-optimization.
BitArray currently requires calling .ToArray() when working with spans, which introduces an unnecessary allocation despite the type already copying internally.
Given the low implementation cost and consistency with modern APIs, it might be worth reconsidering either:
tannergooding commentedon Apr 19, 2026
Marked ready-for-review. Simple improvement that avoids an intermediate allocation and copy.
bartonjs commentedon May 5, 2026
Video
Looks good as proposed
Add ReadOnlySpan constructors to BitArray (#131500)