Added: Notes from October 14th, 2020

[333fred]

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

Agenda

• Triage
• Milestone Simplification

[ufcpp]

Might the title be mistaken? 12th →14th

[333fred]

[yaakov-h]

My thanks to the LDT and our new Ambassadors (I assume) for... well, all of that.

[YairHalberstadt]

New milestones will definitely be appreciated.

[alrz]

params Span
We'll need to carefully design the overload resolution rules such that it wins out over existing params arrays.

Alternatively we could make it an error to define both params Span<T> and params T[] with an identical T. When you add a params span overload, you will need to remove params on the existing one. This is still binary compatible. The only issue with this approach is that this API is only consumable from new compilers (in the expanded form).

Also I think it makes sense to consider params IEnumerable<T> IList<T> etc at the same time to see how they should interact.

[333fred]

Also I think it makes sense to consider params IEnumerable IList etc at the same time to see how they should interact.

I believe @jaredpar's comments on that were that the community would have his head if we did Span without considering the others.

As to only requiring one, we don't think that's necessary, at least initially. It's certainly an option, but it seems like it might be an unnecessary restriction.

[alrz]

One feature that was missing from the triage - the part of pattern-matching spec that was got cut from C# 9.0 and almost lost there.

what if we permit i to be declared in different mutually exclusive patterns?

if ((e1, e2) is (0, int i) or (int i, 0))
{
    M(i);
}

Here, the variable i is definitely assigned inside the block, and takes it value from the other element of the tuple when a zero element is found.

It has also been suggested to permit variables to be (multiply) defined in every case of a case block:

    case (0, int x):
    case (int x, 0):
        Console.WriteLine(x);

To make any of this work, we would have to carefully define where such multiple definitions are permitted and under what conditions such a variable is considered definitely assigned.

Should we elect to defer such work until later

Any chance it could be included in the working set?

[333fred]

@alrz is there a proposal covering it?

[alrz]

Not that I'm aware of.

F# speced that as "Both patterns must bind the same set of variables with the same types." (otherwise they wouldn't be definitely assigned) and I think that's all there is to it. The only interesting cases I could come up with is that the pattern variables may be recursively multiply defined on each side:

if (e is { A: (int x, 0) or (0, int x) } or { B: (int x, 0) or (0, int x) })
  Use(x);

and that each variable should be individually accessible in a when clause:

  case ( (int x, 0) or (0, int x) ) and var a when M(x, a):
  case ( (int x, 0) or (0, int x) ) and var b when N(x, b):
     Use(x); 
     // a and b are not definitely assigned here
     break;

Under the hood, it is the same local being assigned in each pattern.

[333fred]

If there is a proposal I'd be willing to consider it :)

[Unknown6656]

@333fred Would it be possible to close all the old issues?
e.g. https://github.com/dotnet/csharplang/milestone/4 has 12 open issues, most of them can be closed as they're implemented and shipped.

[theunrepentantgeek]

I believe old issues are only closed once the specs are officially updated - which can take quite some time after shipping, as it involves coordination of updates outside of Microsoft.

[Unknown6656]

@theunrepentantgeek ok, fair enough.

[Joe4evr]

Most of them could still do with getting re-tagged, though. Maybe even given a new tag such as Shipped-Needs Spec so that it's more obvious what the status is.

[333fred]

Yep, that's a good idea Joe.

[333fred]

@Joe4evr done, there's a new label for these issues.