Quality-of-life: Treat Count and Length as true synonyms?

[daiplusplus]

Here's a minor pain that happened to me today:

1. Travel back-in-time to the time before generics.
2. Open your typical LoB application: observe that Array types are being passed-around as a cheap-but-effective substitute for strongly-typed immutable or read-only collections, with a team-wide general rule order against ever mutating an Array in-place. So far, so good.
3. .NET Framework 2.0 comes out at the end of 2005, and thanks to a gargantuan effort all of those arrays are replaced with the greatest thing since C++'s sliced objects: ReadOnlyCollection<T>, with the caveat that ReadOnlyCollection<T> is not actually immutable, but there's a new team-wide rule against ever using ReadOnlyCollection<T> as a wrapper over a live mutating collection. That works.
4. A few years later in 2012 and .NET Framework 4.5 comes out with the newfangled IReadOnlyCollection<T> and IReadOnlyList<T> interfaces, which allow almost any collection to be exposed to other components in a software system without fear of those components mutating the data contained within, as well as avoiding the computational cost of copying collections everywhere (assuming you're careful not to pass a live and mutating collection via a read-only interface. Oh, and they support variance too (wow!)
   • With the caveat that IList<T> does not extend IReadOnlyList<T>, and IDictionary<K,V> does not extend IReadOnlyDictionary<K.V> - but that can be worked-around.
   • Unfortunately, 10 years later, this is still a work-in-progress 😩: Make mutable generic collection interfaces implement read-only collection interfaces #31001 (but that's largely off-topic for this discussion).
5. A bit further down the line and System.Collections.Immutable is the new hotness; the great thing with these collection-types is you don't need to be content with hoping that consumers of IReadOnlyList<T> won't try to mutate it themselves by casting to a known mutable collection type - but you also get hard guarantees that the collection won't be live and mutated unexpectedly. This means: another refactoring opportunity to replace all of those IReadOnlyList<T> and IReadOnlyCollection<T> interface types used for public parameters, properties, and return-types can now be typed with as ImmutableArray<T>!
6. However, a simple textual find-and-replace (e.g. replace \bIReadOnlyList\b< with \bImmutableArray\b<) don't go quite as smoothly as expected because, annoyingly, ImmutableArray<T> uses .Length instead of .Count for its size property. Even though until this point all other collection-types have settled on .Count, not .Length. Aieeeeee.
7. So today I had to go through hundreds of compiler-errors to replace broken .Count references with .Length property accessors.

Why was this necessary?

The ImmutableArray<T> type already implements ICollection<T> so it already has a .Count property, but as it's an explicit interface implementation it's only exposed when you use an interface reference.

I understand wanting ImmutableArray<T> to be largely a drop-in replacement for T[], so having a public .Length property does make sense. I'm fine with that. This is the reason given in the introductory blog post:

We’ve decided to go with having a Length property instead of Count because we see ImmutableArray<T> as a replacement for regular arrays. This makes it easier to port existing code. It also makes the design a bit more self-contained.

Of course, I take umbrage with the "This makes it easier to port existing code." part: because it actually made my task to porting existing code harder, not easier).

But what justification was there for not making .Count public too? I appreciate that identically-behaving members do cause confusion, but .NET has had attributes to hide potentially-confusing types and members: EditorBrowsableAttribute and (if you're feeling particularly nasty: DebuggerBrowsableAttribute).

The main reason it's so frustrating is because it's a wart that breaks conceptual isomorphisms about collections for absolutely no good reason (at least as far as category-theory is concerned). The semantics of .Count and .Length for immutable collections are identical, and given the C# compiler isn't yet smart enough to identify isomorphisms, at least the library designers could paper-over it by exposing .Count.

---

The point:

• For the design team: Why was it decided to not at least retain .Count with EditorBrowsable?
• In .NET 7+ can .Count be exposed to allow for source-level compatibility between all the different Collection types?
• It's been a while since I last looked at extending Roslyn - hypothetically, could a Roslyn syntax processor extension allow calls to ImmutableArray<T>.Count be rewritten to .Length transparently?
• Another alternative is extension properties... _{but we aren't going to see that for a long time methinks}

[huoyaoyuan]

For the design team: Why was it decided to not at least retain .Count with EditorBrowsable?

The reason should be not duplicating api with only name difference.

In .NET 7+ can .Count be exposed to allow for source-level compatibility between all the different Collection types?

Probably not. In .NET, source compatibility between different types is not useful, as you can't share source code.

hypothetically, could a Roslyn syntax processor extension allow calls to ImmutableArray<T>.Count be rewritten to .Length transparently?

It "solves" the source-level view, but makes the behinds horrible.

The historical debt of collection interfaces is quite heavy. Adding a partial solution can make things more messed up. There are type system changes proposed with next versions of C#. The unification should be discussed with the updated type system.

[daiplusplus]

What do you mean by "you can't share source code"? I share C# source code all the time...

[huoyaoyuan]

I mean that you can't apply a source snippet to different types via macros or templates. Using #if and using can share between different projects, but can't share different instantiates within a project.

[GSPP]

I hate Count and Length almost as much as I hate Close and Dispose 😄

[EgorBo]

What about Delete and Remove? Add and Append 😄

[daiplusplus]

@EgorBo what commonly used types in .NET have .Delete methods?