Open issue: non-negative assumption should apply to both Count and Length

[jcouv]

Should the non-negative assumption apply to the used Property or both?

The current behavior is shown below. I think we should have an error for both lines.

interface IIndexable
{
    int this[int i] { get; }
}
interface ICountableViaCount
{
    int Count { get; }
}
interface ICountableViaLength
{
    int Length { get; }
}
class X
{
    public static void Test5<T>(T t) where T : IIndexable, ICountableViaLength, ICountableViaCount
    {
        _ = t is { Length: -1 }; // error CS8518: An expression of type 'T' can never match the provided pattern.
        _ = t is { Count: -1 }; // should Count benefit from the assumption when it is not the preferred property?
    }
}

Should we assume that Length and Count have the same value?

Another related question is whether we should assume Length and Count to have the same value? For example: case { Length: > 0 }: case { Count: 0 }: case { Count: var unreachable }:.

Should we assume non-null slice when we expect a non-zero slice?

Should we consider null or { Length: not 4 } => 0, [_, .. [_, _], _] => 0 exhaustive in a nullable context?
It is possible for a type to claim Length=4 but return a null slice, but that would violate our assumption that lengths and elements are consistent between outer and nested lists.

Options:

1. this switch is not exhaustive: this is simpler, safer, but goes slightly against our "well-behaved collection" assumption
2. this switch is exhaustive assuming a well-behaved collection: not sure we want to modify our DAG/codegen for this
3. reject this slice method because it returns a nullable type: this seems odd, as we generally don't want nullability to affect semantics

FYI @alrz @333fred

Relates to proposal #3435
Relates to test plan dotnet/roslyn#51289

[JustNrik]

Something I've always been curious about, why are Length and Count declared as int when they are really never going to be negative? like, shouldn't they be uint instead?

Also, why have two interfaces that are essentially the same when you could just have a single ICountable interface, or perhaps ISizable with Size property?

Should IIndexable really be readonly? couldn't we have IReadOnlyIndexable with IIndexable : IReadOnlyIndexable instead? Or are all of this interfaces just for list patterns features and not general abstraction?

[CyrusNajmabadi]

Unsigned integers were not cls compliant.

[theunrepentantgeek]

When the compiler encounters this line will it already be sure that it's working with a collection or sequence?

 _ = t is { Length: -1 }; // error CS8518: An expression of type 'T' can never match the provided pattern.

If the compiler can't be completely sure that t is an array (or a similar container) then a warning here might be a problem due to differing semantics. Not every Length is strictly non-negative.

[CyrusNajmabadi]

Our position is that it's fine for the language to assume these types are well behaved for the purposes of pattern matching.

[FaustVX]

Why not put an attribute on the correct length property (like IndexableLength)
This will allow to have any name for the property we want (Count, Length, Size, even other language Longueur)
Maybe with a parameter to allow negative value.

class C {
  public object this[int i] { get; }
  [IndexableLength(allowNegative = false)]
  public int Size { get; }
}

_ = new C() is { Size: -1 }; // error

[CyrusNajmabadi]

Why not put an attribute on the correct length property (like IndexableLength)

Because the APIs have already shipped, and we'd want patterns to work across the enormous ecosystem of well-behaving types already out there.

[333fred]

When the compiler encounters this line will it already be sure that it's working with a collection or sequence?

Yes, it will only make this assumption when the type is both Countable and Indexable, where those words come from the index and range feature in C# 8.

[alrz]

I suppose LongLength would be out of scope here because it doesn't have any special meaning.

[jcouv]

FYI, I added a third question to OP for Wednesday:
Should we consider null or { Length: not 4 } => 0, [_, .. [_, _], _] => 0 exhaustive in a nullable-enabled context?

[jcouv]

This was discussed in LDM 10/20/2021. In short:

1. only Length or Count gets the benefit of the non-negative assumption
2. Length and Count are not assumed to be consistent
3. produce an exhaustiveness diagnostic
   All the above are subject to revision based on user feedback.

[alrz]

1. only Length or Count gets the benefit of the non-negative assumption

Does this mean:

• If both are present, only one of them is assumed to be non-negative, or
• We won't consider anything else like LongLength in this assumption.

[jcouv]

The former "If both are present, only one of them is assumed to be non-negative". If there is a Length, then we say/assume nothing about Count.
I realize that's what you'd implemented initially. Sorry for the reversal.