Added: LDM Notes for May 26th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-05-26.md

Agenda

1. Open questions in list patterns

[smoothdeveloper]

@333fred, wondering if the LDM notes are more for "later referal in future meeting on same topic" or for engaging with people outside the meeting participants, that would like to contribute feedback?

I personally enjoy the notes being published, but seem to have difficulty to connect with the context that maybe obvious when you are in the meeting, because for exemple, in this case, there is no reference material, to at least scope better at first glance, what it is about, until I've finished a cursory reading.

Suggestions for this:

• having an introductory paragraph from the external parties, with, if possible few links, but mainly a "heads up" summary of what the topic is, if someone stepped in the meeting without knowing the agenda nor the topic in particular
• putting pseudo code / examples that maybe were hashed on during the meeting would help in that aim
• encapsulating pros/cons that accreted during the discussion (this also make referral in later LDM quicker than reading the whole notes again)

Small feedback of what I gleaned:

We first revisited the question of what to allow after a .. pattern. Previously we stated that any possible pattern should be allowable in this position; however, there is some concern that this could be confusing to code readers.

It would be great to see pseudo code of what would be confusing to code readers in the context of that statement.

Given our concerns with the first two approaches, we think that, despite earlier concerns, approach 3 is the way to go. We can take a stronger stance in the IDE and our documentation with fixers and best practices to help ensure that nested patterns don't get too crazy here.

This sounds great, conceptually, pattern should remain composable, the patterns may be little "involved" but they do encode things most concisely and statically compared to the structures they end up desugaring to (nested if/else/switch, etc.), so reasoning about code, after being acquainted to the pattern syntax eventually become easier than the expanded form.

Tests emitted for { .. }

⚠️ tangent...

Wondering if as an alternative of baking custom pattern syntax in the language as hardcoded implementation details, you would be considering options where the C# compiler has definitions like "macros" that monomorphizes at the instanciation site.

A bit like, what I believe, some of the foreach or async/await figures if type is "enumerable like" or "task like" in a duck typing manner, and those macros would be used like keyword or method call:

pattern NonEmpty(list_like list){
  if(has_prop(int Length, list)) {
    // implementation of pattern if Length exists
  }
  else if(has_prop(int Count, list)) {

  } else {
    // substitution failure is a compile error, saying nice things about list like and what the code tried to pattern match over
  } 
}

using it:

 x switch {
  NonEmpty => ...
}

If there is a concern about mixing with normal identifiers, the pattern may be adorned with a special character, or couple of them, indicating the nature of the construct.

Taking this approach to extend patterns would:

• avoid a pitfall of too many new operators coming quickly into the language
• not be confusing to users that haven't been acquainted with
• defer picking highly used patterns and turning them into operator syntax, later on when it is established they are used a lot

The patterns could even look a bit like keywords instead of dotnet BCL identifiers.

If C# extends internally this way, and does so successfully in terms of tooling support and end user experience, the infrastructure would later possibly be for C# code authors to leverage, enabling scenarios similar to F# active pattern (which are much simpler concept as they just desugar to methods returning Choice<,,,,,,,> objects of varying arity).

I personally don't enjoy patterns leaning heavily on operator syntax unless the operators tend to carry outside the pattern matching situations, AFAIK, there is no {..} construct in C#, despite I can connect the ".Add" and list like initialization, given C# is curly brace heavy, { .. } may look a bit confusing.

Have you considered those:

x switch {
  []{a, b} => // match 2 element array
  List<int>{a,b} => // match 2 element List<int>
  NonEmpty => // anything list like, which is non empty
  _ => // anything else 
}

Sorry for digression, and looking forward for future LDM notes :)

[HaloFour]

Perhaps for a complicated feature like this the notes could include links to previous discussions and meeting notes? There are some pretty good and very detailed specs written up for list patterns that these meeting notes builds on.

[333fred]

I did forget to include a link to the proposal today, I normally do. In terms of linking to past notes, that's what the year-specific READMEs are for. Yes, it may take a CTRL+F or two to find the last notes on the topic, but attempting to keep anything but a centralized list of notes and agendas up to date is not something I'm interested in trying to maintain :). The topics of the day are covered in the headers. When topics aren't obvious from the name of the section I do try to include info, but yesterday's topics were pretty self-explanatory and I didn't feel it was necessary to include more detail.

[smoothdeveloper]

thanks @HaloFour & @333fred

Found purpose of meetings: https://github.com/dotnet/csharplang/blob/main/meetings/README.md#purpose-of-the-meetings-notes and it seems to align a bit with some hypothesis I made.

And yearly archives: https://github.com/dotnet/csharplang/tree/main/meetings/2021

Yes, it may take a CTRL+F or two to find the last notes on the topic

More context why I lacked this: I'm just watching the repository, I don't have it checked out on filesystem, and it seems the activity altering the files doesn't surface as PR / Issues / Discussions as frequently of what comes in my inbox.

I'll pay attention to the repo contents itself and give a shot at tracking the activity that gets merged in outside of PR, which is easily overlooked when you are just "watching" the repo and not in the known of the larger, well defined & established process.

but attempting to keep anything but a centralized list of notes and agendas up to date is not something I'm interested in trying to maintain :)

understood, and thanks a lot for what's already surfacing.

[omariom]

A small discussion in Twitter shows that almost no one can guess what if (list is [0]) is

https://twitter.com/controlflow/status/1399648848780398593

[HaloFour]

Yet they all probably know exactly what the following does:

var array = new int[0] { };

I can see how some might conflate it with how lists work in other languages, but C# has never used [] to define the elements within a list. Syntax is learned once.

As an alternative to having a length pattern, I could see supporting property patterns mixed with collection/list patterns, like the following:

if (list is { Length: 3, var item1, var item2, var item3 }) ...

But I think that would go with having C# also support mixing object and collection initializers:

var x = new SomeCollection() { Property = 123, "foo", "bar", "baz" };

[omariom]

Yet they all probably know exactly what the following does:
var array = new int[0] { };

It could be then if (obj is int[0]) or if (list is var[0])

[HaloFour]

@alrz

If we go with this as a recursive pattern, in my mind, you either have a property pattern clause (possibly including indexers) or a list, anything beyond that should fallback to using and, that's what it's there for.

That makes sense, however that does suffer from the problem that { } is already legal as a property pattern and cannot represent an empty list pattern.

[alrz]

Yeah that's going to be still an issue. all things considered, { void } is my favorite alternative /jk

[333fred]

Yeah that's going to be still an issue. all things considered, { void } is my favorite alternative /jk

FWIW, we're going to be talking about the concerns you all have raised soon. Also, while @jcouv, @CyrusNajmabadi, and I were brainstorming up ideas, { void } was actually a version we considered :P.

[alrz]

Ship it

[DavidArno]

@HaloFour,

No it doesn't. But given how type patterns and length patterns interact with each other my ask would be to drop length patterns on the floor entirely...

Whilst your use case of if (o is { Count: 0 }) { ... } instead of if (o is [0]) { ... } makes total sense as it's far more readable and not much longer, to my mind the power of length patterns will lie in using ranges, eg:

if (o is { Count: 0 } or { Count: 1 } or { Count: 2 } or { Count: 3 }) { ... }
versus
if (o is [0 .. 4]) { ... }
(Assuming I'm ready the proposal correctly and that will be a thing)

Scratch all that. It occurred to me after posting that if (o is { Count: >= 0 and < 4 }) { ... } is a thing, so if (o is [0 .. 4]) { ... } just seems another way of saying that. I'm tempted to agree therefore that it makes sense to drop length patterns as they don't really add anything other than an alternative syntax.