Discussion: indexer patterns

[alrz]

While list-patterns cover this use case to some extend, they get too verbose when patterns are not sequential, such as matching the nth element. e is [ _, _, _, pat ]

Indexer patterns would be an addition to property subpatterns:

case { [0]: pat }:
case { name[0]: pat }:
case { [0].name[0]: pat }:

Any non-empty list of constant expressions may be used as the indexer arguments.

If the type is countable and indexable, we emit the length check depending on the argument.

case { [5]: pat }: // e.Length >= 5 && e[5] is pat

Otherwise, we bind a TryGetValue(T, out V) instance method.

case { [5]: pat }: // e.TryGetValue(5, out var v) && v is is pat

--

To make this more useful, we need to accept non-constants inside patterns.
The following "pseudo-constants" could be permitted as the indexer argument:

• variable references -- assignment of such variables are not allowed in a when_clause
• ^e1 where e1 is a pseudo-constant
• e1..e2 where e1 and e2 are pseudo-constants
• typeof(T)
• etc.

This permits a safe collection access with a non-constant indexer argument:

case { [index]: pat }: // index >= 0 && e.Length >= index && e[index] is pat

Range expressions are special here because we can deduce a minimum length based on the value.

case { [^1]: pat }: // e.Length >= 1 && e[^1] is pat
case { [^2..]: pat }: // e.Length >= 2 && e[^2..] is pat

These expressions will be inlined inside the invocation, so they may be evaluated multiple times. That is, we don't capture such expressions in a temp. That's why we need to make sure these expressions are side-effect free.

--

The same concept can be applied to patterns themselves, permitting:

bool M(int value) => e is { Prop: value };

Since we're matching the value rather than just passing it, we need to distinguish between value and reference equality.

• Matching by value: Using the same semantic as auto-generated record Equals method.
  case { Prop: obj } // EqualityComparer<T>.Default.Equals(e.Prop, obj)

• Matching by reference: Allow to ditch value semantics and use a simple reference comparison.
  case { Prop: ref obj } // object.ReferenceEquals(e.Prop, obj)

This permits more complex argument validation using pattern matching which is currently limited to constants.

[YairHalberstadt]

Would this bind to the Countable pattern or TryGetValue for Dictionary<int, ?>?

[alrz]

Dictionary<int, ?> doesn't satisfy the indexable requirement because we need an exact this[int] member, no substitution is allowed, so it binds to TryGetValue.

[jnm2]

I would like to be able to use dictionary indexers with syntax like { ["foo"]: { } foo }.

[333fred]

I would also hope that the pattern would be able to match against dictionaries.

[KalleOlaviNiemitalo]

I'd like it to match against non-generic IDictionary too, as in Exception.Data. Perhaps that could be covered by defining a TryGetValue extension method in the application. The IDictionary.this[object key] indexer getter is documented to return null when the key is not found.

[333fred]

While I get where you're coming from with the variable references as "pseudo-constants", I don't think that's appropriate to allow as part of this proposal. It will effectively force us to solve the exhaustiveness problem that introducing any non-constant expression into patterns would create. While I'm not necessarily opposed to such a change, I think it needs to be a separate proposal and not part of this one.

[alrz]

Yes this definitely needs to get split into three proposals, I just wanted to start a discussion to explore how they may interact.

For instance, we could make ranges a special case for indexer patterns (if we want to support it at all), but I wanted to see if a generalization could work here. And if it does, how do we feel about using the same concept for the match itself, etc.