Added: LDM Notes for December 14th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-12-14.md

Agenda

• List patterns

[qrli]

My immediate reaction is same as 3.iii []{ ... }?

• It matches array initialization syntax.
• Empty collection would be []{ } or [0]{ }
• Array would be tricky though int[] []{}. One idea is to special case array to omit the extra [], but I guess that may already work as object property match today.

For matching property and collection together, one idea is List<int> { Count: 3, []: []{ 0, 1, 2 } }, where []: feels like referring to this[int index].

[alrz]

I agree with this. though I don't think int[] []{} is an issue. If this is a new syntax for list patterns, it doesn't have to include a type.

I imagine if we only permit constants for the length, it will be a lot simpler and less corner cases overall.

case []{}: // implicit length
case [0]{}: // explicit length
case [1]{}: // error: list pattern of length '1' expected

(Note that this should be considered in the context of deconstruction and multi-dimensional arrays as well. Plus, it's not clear how slice patterns fit into this picture)

We could allow sized arrays T[N] as a pattern to match type and length at the same time but that would be an entirely separate feature.

[Phantonia]

Is there a grammatical reason for the []:? I could be wrong, but I feel like { Count: 3, [] { 0, 1, 2 } } would also be unambigous while not requiring the []:.

[erikhermansson79]

I like [...]{ ... } as it allows for length patterns and content patterns at the same time.

I would also like a simple syntax for matching head and tail in a collection. Maybe [] { head, ..tail }?

I would like to be able to use patterns for dictionary keys as well: [] { [var key]: "some value" } or [] { [var userId]: { Parent: { Id: 42 } } }.
I'm not sure the length brackets are useful for dictionaries, but maybe they are.

[333fred]

At least in my head, I wasn't imagining 3.iii as a nested pattern like this (which is really a combination of 3.iii and 2). I was imagining the empty case, for example, as x is [0], and the 2 explicit element case as x is { 1, 2, }. You would be able to provide both components if you so chose, like [10] { 1, 2, .. }, but I'm personally not a huge fan of requiring the collection pattern to be nested inside a property pattern.

[alrz]

x is [0] to check length is a no-go for me, every language I know use brackets for list patterns, using that (alone) to check length is extremely confusing IMO.

nevertheless, it would be nice if we could skip it when it's not ambiguous. so []{}, [0]{}, [1]{ 1 }, { 1 } would be all valid.

[spydacarnage]

Is it worth considering the [| 1, 2, 3 |] pattern that F# uses for arrays?

…

On Tue, 15 Dec 2020 at 08:12, Erik Hermansson ***@***.***> wrote: I would like to be able to use patterns for dictionary keys as well: [] { [var key]: "some value" } or [] { [var userId]: { Parent: { Id: 42 } } }. I'm not sure the length brackets are useful for dictionaries, but maybe they are. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADIEDQJ7AZV53VRWVTSD3EDSU4K7TANCNFSM4U3P4O2A> .

[333fred]

@jaredpar mentioned this after the meeting, actually.

[orthoxerox]

tangential: Why is the decomposition of a class written as p.X when the decomposition of a tuple is (int x, int y) = p? One is RHS, the other is LHS. I swear there used to be a proposal for property-based decomposition somewhere...

On the meeting notes themselves:

• separate syntax for Length/Count: I like the idea
• leading ..: I think allowing it will lead to more problems than it solves.
  • On one hand, Enumerable.Count() already exists
  • On the other hand, that's digging the pit of failure even deeper
  • If leading .. on foreachables is disallowed, then the programmer is stuck with
    • Writing a collector by hand (error-prone)
    • Calling ToList() and using leading .. (safer, but space-inefficient)
    • Both are worse than a leading .. on the enumerable
    • But that's still worse than pushing the programmer to restructure their code so they don't have to pattern match the tail of an foreachable!
  • I'd rather push a helper method to NuGet that collects the tail of a foreachable into a length-N list

[YairHalberstadt]

I swear there used to be a proposal for property-based decomposition somewhere

#4082

[MgSam]

I'm strongly against enabling length checks against IEnumerable. As the notes suggest, this is a pit of failure for the (extremely common) scenario where developers don't understand IEnumerable or how it works and that checking its length means enumerating the whole thing. Length checks should require ICollection.

The length or count of the collection could also be extracted with a declaration pattern, which could turn into a nice shorthand for not having to know whether this collection uses Length or Count, something we didn't standardize and now can't.

This isn't quite true. Arrays implement ICollection. They just implement Count explicitly so it's usually hidden. AFAIK, you can use Count to check the size of any collection.

ICollection a = new[] { 1, 2, 3 }; 
Console.WriteLine(a.Count);

[YairHalberstadt]

AFAIK, you can use Count to check the size of any collection.

That would box e.g. ImmutableArray

[jaredpar]

Pattern matching IEnumerable<T> against a length does seem like a potential pitfall. However I do think we need to support pattern checks against an empty IEnumerable<T>.

[Richiban]

I'm sure you're already aware but it's possibly worth noting still that F# never implemented pattern matching against IEnumerable because it was a snake pit of possible issues... I hope you guys know what you're getting in for! :)

[jaredpar]

Generalized support yes is a potential pitfall of issues. There are a subset of pattern matching operations that are reasonable like: empty or starts with. Those can be implemented efficiently, have no particular implementation challenges and users can trust will work as expected. For me the bigger question is it acceptable to only implement part of pattern matching against enumerable and leave the other part explicitly not done. Will that disconnect cause more problems for users than the feature brings in value.

[canton7]

Add a new combinator keyword to make the transition to a collection pattern explicit

I like this. We already have good syntax for testing e.g. Length or Count, and I don't like the idea of introducing another way of doing this.

The user can also implement their own types implementing e.g. IList<T>, and it would be nice to support matching on properties of that object, as well as its items.

So, how about a strawman, using a new keyword to match on the items returned by an object's enumerator (items and { } entirely made up):

o is int[] { Count: 3 }

// .GetEnumerator() returns an enumerator which yields exactly these 3 items, or optimized equivalent
o is int[] { items { 1, 2, 3 } }

// Redundant? But possible!
o is int[] { Count: 3, items { 1, 2, 3 } } 

// .GetEnumerator().MoveNext() return false, or optimized equivalent
o is int[] { items { } } 

Then this could work with the proposed [key]: <value pattern> syntax for matching on an object's indexer:

// Indexer yields these values when given these keys
o is int[] { [0]: 1, [1]: 2 }

Of course, extended to objects which have indexers which take multiple parameters:

o is SomeObject { [1, 2]: 3 }

These apply to all types which have an indexer / enumerator:

// Again, matches using the indexer
o is Dictionary<string, string> { ["a"]: "b" }

// Matches the `KeyValuePairs` returned from its enumerator (in order)
o is SortedDictionary<string, string> { items { KeyValuePair<string, string>("a", "b"), KeyValuePair<string, string>("c", "d") } }
// Equivalently
o is SortedDictionary<string, string> { items { ("a", "b"), ("c", "d") } }

---

The length or count of the collection could also be extracted with a declaration pattern, which could turn into a nice shorthand for not having to know whether this collection uses Length or Count, something we didn't standardize and now can't.

Developers need to know this anyway: that ship sailed when .Count was first introduced. I'd be more surprised if there was a uniform way of getting the length, to be honest. I'm used to checking .Length / .Count in if statements currently, and I'm fine with continuing to do this with patterns.

[BhaaLseN]

I wanted to write this piece of code the other day:

if (Regex.Match(input, "prefix_(?<num>\\d+)") is { Success: true, Groups: { ["num"]: { Success: true, Value: string n } } } && int.TryParse(n, out int num))
{
    // use num
}

Obviously didn't work like that, and while I'm not totally sure about the syntax, I was wondering if this was included here as part of "list" patterns (since Group is a GroupCollection that might fall into that class).

What I wrote instead (because it works today) is this:

if (Regex.Match(input, "prefix_(?<num>\\d+)") is { Success: true } match && match.Groups["num"].Success && int.TryParse(match.Groups["num"].Value, out int num))
{
    // use num
}

Also, while I was typing this, I noticed that the former is pretty verbose and often longer than the classic alternative once you use a variable name longer than 3 characters (such as numString), so this might as well be a case of "hey, this is new, it must be better!" being a bit awkward.

[alrz]

Also, while I was typing this, I noticed that the former is pretty verbose and often longer than the classic alternative

For regex and such I think #4131 is a better solution if you want to use patterns.

[jnm2]

I've had a few times where I really wanted to match using indexers. E.g. { [1]: var secondParameter } against a parameter collection.

[Richiban]

I'm not sure I like the syntax of the x is [] { ... } pattern for general list-shaped deconstruction because the var x = new [] { ... } form is used specifically for arrays. I think here the symmetry beween construction and deconstruction is a false friend and potentially detrimental.

[erikhermansson79]

Why?