Could we have a count operator?

[bennidhamma]

Is it Length? Or is it Count? Or is it Count()? Who cares!?

Wouldn't it be nice if we could do something like:

var a = new [] { 1, 2, 3 };
var b = new[] {1};
var c = |a| - |b|; // c = 3 - 1 = 2
for(int i = 0; i < |a|; i++) // enumerates from 0 to length of a.
  ...

?

[HaloFour]

Sounds like a lot of complexity for very little utility. Having to explicitly specify the member you want to reference builds on existing language semantics and puts the control in the hands of the developer, which is good thing especially when Length and Count() might both exist but mean very different things.

[bennidhamma]

Hmm. I see it as sort of piggy backing off the rationale described for ranges and indices:

The language will provide an instance indexer member with a single parameter of type Index for types which meet the following criteria:

The type is Countable.
The type has an accessible instance indexer which takes a single int as the argument.
The type does not have an accessible instance indexer which takes an Index as the first parameter. The Index must be the only parameter or the remaining parameters must be optional.
A type is Countable if it has a property named Length or Count with an accessible getter and a return type of int. The language can make use of this property to convert an expression of type Index into an int at the point of the expression without the need to use the type Index at all. In case both Length and Count are present, Length will be preferred. For simplicity going forward, the proposal will use the name Length to represent Count or Length.

(link)

In that sense, there is already a notion for language level operators trusting implicit properties of Length or Count to add ease of use for authors.

The vertical bars are used all over the place in math and in research papers to consistently reference the length of a vector. I feel like it would be easier to both a) implement algorithms found in math or in technical papers in c# if this was a feature, and b) would familiarize folks with that syntax and help make reading research papers a bit more friendly.

[RikkiGibson]

Recent LDM meetings have raised the question of whether to introduce a "length pattern" as part of the list patterns feature. This suggestion seems related. https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-12-16.md#list-patterns

For example, if a length pattern were introduced to the language, it might become possible to say something like expr is [var length], and then go on to use it.

I'm pretty fuzzy on where the LDM is currently with this concept more recently, so take with a grain of salt, as I'm referring to something that's in the early stages of design.

[HaloFour]

It was discussed in the last Language Design Meeting in the context of pattern matching on IEnumerable<T>:

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-02-03.md#list-patterns-on-ienumerable

Example:

if (enumerable is [<6] { 1, 2, 3, .., var last }) { }

[bennidhamma]

One more data point: the fact that Rider IDE offers both Length and a Count autocomplete options for collections, but then self-corrects the choice of Length to Count, says something about this odd, yet all too common area in c#.

I stumble across this all the time. There are numerous scenarios where I change a data structure from a list to an array (or vice-versa), and the fact that this property now becomes a compile error just feels like something I shouldn't have to worry about.

[CyrusNajmabadi]

and the fact that this property now becomes a compile error just feels like something I shouldn't have to worry about.

This coudl be provided with an analyzer. The changing of intellisense can be provided with a completion-extension. My preference would be that this not have to be stuff that is baked in, but can be added value externally

[alrz]

My preference would be that this not have to be stuff that is baked in, but can be added value externally

Why? I think it's a common developer experience that you might type Length/Count interchangeably but the intent is the same. Worth noting that this issue has been found its way to the language already. Range indexers look for both properties.

I think this proposal is trying to solve exactly that which IMO is easier to be addressed with a built-in IDE feature.

[canton7]

Obligatory xkcd:

We've got Enumerable.Count which works everywhere (and delegates to .Length or .Count if it can). I don't think adding a 4th way of doing the same thing helps anything.

[yaakov-h]

Wasn't adding IEnumerable.Count the poster-child example of why DIM was needed though?

[HaloFour]

I think it was offered as a simple example of a case where it could be useful but was also regarded as a counter-example given such a default member would probably be a terrible idea.