Added: Notes for November 16th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-11-16.md

Agenda

• Triage

[BreyerW]

Wow working set ended up pretty large even if half of features gonna span several c# versions

Btw this working set theme should get pinned i think since comments are blocked and as such its going to get buried relatively fast

Edit:
Also Type class section lack shapes proposal i believe?

[alrz]

Nominal and collection deconstruction

One thing we want to be careful of here is to not go to far down the path of replicating patterns in assignment.

I think it makes sense to just exclude var {p:q} = e syntax, that doesn't seem to be too useful. We don't have e is var {p:q} either so if we ever follow that path we immediately lose pattern syntax symmetry and it'll require more work to make it so.

My suggestion is that we only consider what's possible in patterns today, permitting { P: var x } = e;. That doesn't introduce any new syntax to the mix and we have closed the gap between deconstruction assignment and patterns by just doing that.

Ternary comparison operator

all comparisons in a chain should be less-than/less-than-or-equal, or greater-than/greater-than-or-equal, without mixing between the 2 orders

IMO That's too much language baggage for a feature that we have covered using relational patterns.

Also chained relational operators doesn't provide a straightforward way to be negated - we'll still need to write if (!(x < y < z)) throw unless we have if! syntax. so the feature on its own doesn't cover all the scenarios it's targetting.

Just my 2c.

[333fred]

We don't have e is var {p:q} either so if we ever follow that path we immediately lose pattern syntax symmetry and it'll require more work to make it so.

We don't have e is var (a, b), but the opposite form is useful. The single variable example only shifts the var around, but the multivariable example has real savings.