Added: LDM Notes for June 14th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-06-14.md

Agenda

1. Open questions in CallerArgumentExpressionAttribute
2. List pattern syntax

[BreyerW]

Will the indexer for list pattern require int parameter or other flavours will be supported too? Index and Range specifically.

Also you mentioned that not much time left to freeze c# 10 feature set and i would like to ask status on field keyword since it is missing from work matrix in roslyn repo so i cant check it myself

[CyrusNajmabadi]

field is def not happening for initial c#10 release.

[BreyerW]

Thanks for answer too bad was excited for it considering how ubiqitous are half complex properties (eg auto prop with added onpropertychanged support)

[Joe4evr]

Sad, but understandable.

[YairHalberstadt]

If [] is used for collection patterns, then the base case is ambiguous with array patterns instead of property patterns so I don't see what that gains us?

x is List<int> []

[333fred]

So this might be allowed in recursive patterns, but not mixed with type patterns?

TBD. Personally, my position is no, but I'm one person 🙂.

[jnm2]

That's a good thought. I can think of a couple of mitigations. expr is List<int> [] will be marked as an error if expr is IEnumerable<int>, so it's probably only nongeneric/object cases that are affected. In such cases, the IDE could squiggle List<int> [] and say something to the effect that array type syntax is clearer without a space separating the element type and the brackets. Even just as a suggestion squiggle, that would get my attention onto the fact that the IDE is interpreting what I wrote differently than I intended.

[CyrusNajmabadi]

Doesn't this still suffer from the problem that you would expect List []

This already means something today, and will keep its meaning. It also means the intuitive thing in my mind as it looks like an array type and will do exactly that type check.

[YairHalberstadt]

It's the intuitive thing if you start off with a type pattern. But if you start off with an empty collection pattern, and then add a type pattern the intuition goes the other way.

[CyrusNajmabadi]

As mentioned above, I do not think this will be common. So I'm ok with it being the one case that is a bit clunky.

From my perspective, I expect list patterns to be used much more to match things with known types that match the list-shape. I do not expect to see many cases where you start off with something unknown and have to both coerce to a type and check the elements.

[erikhermansson79]

Did you consider my suggestion to always use square brackets AND curly braces for list patterns?

[ lengthpattern ] { itempattern }.

[]{} or [0]{} -> the empty list.
[ > 0 ]{} -> a non-empty list.
[]{ 0 } -> a list with only one item.
[ > 3 and var length]{ var head, ..var tail } -> get the first item, the rest of the list, and the length for lists with more than 3 items.

[erikhermansson79]

I saw that someone had asked people on Twitter to guess what (list is [0]) is. (#4787 (comment))

And I agree that list is [0] could be confusing and I don't know if the curly braces where optional in that design, but I haven't seen anyone react to list is [0]{ } or list is [ ]{ }, which, for me at least, is not confusing. But maybe it is to some. I think it would mirror how arrays are declared.

[CyrusNajmabadi]

@erikhermansson79 this suffers from the same problems mentioned. Namely that you have to jump from matching { 0 } to [0] {}. If you have a switch and you have a lot of list patterns in it, we would like them all to be complimentary with each other wrt syntax.

So, to make it clear: we do not want a specialized syntax for the empty case. We want the empty case to be the same as the non-empty case, just with fewer element patterns provided.

All other things being equal, proposals that do not provide that are likely non-starters.

[HaloFour]

I think it would mirror how arrays are declared.

That was the original goal, but the confusion remains that { } means something with patterns, and it doesn't mean an empty list. For example, o is int[] { } is already legal syntax. At best that might work if the length pattern required a recursive pattern, e.g. o is int[_] { } or o is int[0] { }.

[erikhermansson79]

this suffers from the same problems mentioned. Namely that you have to jump from matching { 0 } to [0] {}.

I understand, but I want to point out that { 0 } would not be legal syntax for list patterns in my design. It would have to be []{ 0 }, but as HaloFour wrote o is int[] { } is already legal syntax. I would be fine with the length pattern being required and I would have to use a discard. list is [_]{ }, list is [_] { 0 }, list is [_] { 0, 1 } looks really nice to me.

[CyrusNajmabadi]

looks really nice to me

To each their own :-)

I like the form we settled on. It's clean and consistent. And the 'bad' part if it feels like the least bad of all the options presented :-)

[qrli]

What about putting length after {} like in new List<int>() { 1, 2, 3, 4, 5 }.Count == 5
It will look like: x is List<int> { 1, 2, .. }.Count: 5
Empty case: x is { }.Count: 0

[CyrusNajmabadi]

Lot of readability issues there. A prop pattern with dot and colon. A cliff from { 1 } to { }.Length: 0, etc.

[DavidArno]

Given that the changes we've made today are specifically driven by community feedback, we feel that this feature needs more bake time than is left in the C# 10 cycle. The feature will ship in preview, either with C# 10 (like static abstracts in interfaces) or shortly after 10 is released.

Going off at a tangent to the topic of this thread, but is it documented anywhere how having a preview feature (static abstracts in interfaces) in the release of C# 10 will work? Thanks.

[333fred]

It'll be like using a preview feature at any other time. Static abstracts will be "viral" though, as it's both runtime preview and language preview. See https://github.com/dotnet/designs/blob/main/accepted/2021/preview-features/preview-features.md.

[DavidArno]

Perfect. Thanks for the link, @333fred. 👍

[HaloFour]

This was cleared up in Discord but I got the impression reading these notes that the decision was to keep to the square brackets denoting a length pattern and the curly brackets denoting the items. I think a quick example highlighting the syntax and behavior of the "original" proposal might have helped to clarify the options and the result of the decision.

To make sure that I'm still not wrong I'll post some syntax and my interpretations of that syntax and you can let me know how off-base I am:

// given
List<string> list = new List<string>() { "foo", "bar", "baz" };
int[] array = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

// collection contains exactly specific items
Debug.Assert(list is ["foo", "bar", "baz"]);
// collection starts with specific items
Debug.Assert(list is ["foo", .. ]);
// collection has at least one item and extract the last item into a variable pattern
Debug.Assert(list is [ .., var temp1] && temp1 == "baz");
// collection has a specific length and first/last items
Debug.Assert(list is { Count: 3 } and ["foo", .., "baz"]);

// array starts with specific items
Debug.Assert(array is [1, 2, .. ]);
// array has a minimum length and extract the last item into a variable pattern
Debug.Assert(array is { Length: >5 } and [.., var last] && last == 10);

object o = array;
// object is an int array and starts/ends with specific items
Debug.Assert(o is int[] and [1 , .., 10]);

[333fred]

See https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-06-14.md#length-patterns

Given that we've chosen square brackets for our new list pattern syntax, option 3 is out. This leaves us with option 1 or 2. We originally wanted special length patterns in the language because we wanted list patterns to work on a type that didn't have a Length or Count property: IEnumerable. While we still want to do this, the implementation work is quite complex and we think that it might not get into the initial version. So, while we're not ruling out 1, we don't think it's necessary quite yet.

[CyrusNajmabadi]

You do lose the ability to check the length of IEnumerable

Note: that may only be temporary. What we want are good real world cases where checking such a length is really important. That will help motivate a particular solution.

While it's a shame to lose the symmetry

This may also be temporary. I would champion a proposal to allow for a new target typed list syntax. In such a world, then we'd have symmetry between construction and pattern matching :-)

[alrz]

I would champion a proposal to allow for a new target typed list syntax

I'm wondering what advantage that could give us compared to new() { 1, 2, 3 }

[alrz]

FWIW, I think length patterns could be added in the list itself, something like [5; ..].
(This is sort of similar to Rust's sized "array" types: [T; SIZE])

[CyrusNajmabadi]

For one thing, new() { 1,2,3 } doesn't work with immutablearray. For another, it (and new[]{...}) are both very verbose.