Added: LDM Notes for June 7th, 2021

[333fred]

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

Agenda

1. Runtime checks for parameterless struct constructors
2. List patterns
   a. Exhaustiveness
   b. Length pattern feedback

[erikhermansson79]

My suggestion for list patterns is to always have both brackets and curly braces, even if they are empty. So the empty list would be []{} or [0]{}.

[MgSam]

I've read the list pattern proposal more than once and the design notes and I still have absolutely no idea what

_ = list switch
{
    { .., >= 0 } => 1,
    { < 0 } => 2,
    { Count: <= 0 or > 1 } => 3,
};

or

_ = list switch
{
    { .., >= 0 } => 1,
    { ..{ .., < 0 } } => 3,
};

are supposed to do. I'm really am not a fan of features that ditch clarity in favor of brevity.

[CyrusNajmabadi]

The second switch isn't meant as an example of what you should write. It's meant for us to explore what it would mean if someone wrote it. It's meant so we can determine what invariatns should/shouldn't hold true. For completeness though:

{ ..{ .., < 0 } }

This means you have have any number of elements in your list. However, those elements themselves can have any number of elements, but must end with an element that is less than 0. Intuitively, that means that it should be the same as { .., < 0 }. However, nothing in the spec made that claim. This meeting was about us defining the rules such that from the language perspective we do consider those as having the same meanign for the purposes of our own analysis of your code. It is not a recommendation that anyone actually write this.

[bernd5]

@CyrusNajmabadi Good comment - I was just surprised about { Count: != 1 } - AFAIK this is currently invalid syntax. You would have to write {Count: not 1}.
Is that syntax planed for future versions of C#?

[jnm2]

I'm really am not a fan of features that ditch clarity in favor of brevity.

As counterpoint, it's painful to me to have to exit out of a nested pattern and capture a new variable and then index into it as a separate pattern. Nested { Arguments: { _, { X: Y } secondArgument, .. } } is a lot nicer than having to declare a variable for the arguments list and then index into it as a separate pattern.

[333fred]

@CyrusNajmabadi Good comment - I was just surprised about { Count: != 1 } - AFAIK this is currently invalid syntax. You would have to write {Count: not 1}.
Is that syntax planed for future versions of C#?

No, it is not.

[MgSam]

Thanks all for the explanations.

It feels a little weird to me to have yet another way to refer to items from the end of a list, given that [^1] was just added not all that long ago. That said, I can't really think of a good way to integrate that syntax with what this syntax is trying to accomplish.

[amis92]

What if list patterns, list deconstructors, and a new list initialization pattern is added as well for symmetry - this time maybe taking immutable/init-only lists as well?

It'd require a new list syntax overall. Maybe [| a, b |] as F# has?

[HaloFour]

See: #4830 (comment)

[amis92]

Thanks all for the responses. Cyrus's comment about possible new list construction syntax gives me hope though that not all is lost for immutable collections :)

[HaloFour]

I don't believe the conversation waded into immutable collections, only that the compiler would support a new form of collection initializer with target typing, e.g. List<int> list = [ 1, 2, 3, 4, 5 ];. Perhaps a new discussion should be started for the list initialization syntax and these kinds of questions can be put on the table.

[CyrusNajmabadi]

A new discussion woudl be good (if we don't have one already). I can state emphatically though that i'm only in support of a list-literal proposal that supports immutable collections :)

[HaloFour]

There's #414 which focuses on dictionary literals but also touches on list literals (enough so that future list literal proposals were closed as dupes referencing it).

IMO it's probably worthwhile to consider both list/dictionary literals and corresponding patterns at the same time. And it's a great opportunity to review all of the cases where current collection/indexer initializer syntax isn't suitable due to being inefficient or expecting to mutate the current instance.