Added: LDM Notes for September 15th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-15.md

Agenda:

• Feedback from the C# standardization committee
• Permit pattern variables under disjunctive patterns

[Phantonia]

Do you have an example of "unpredictable effects" of an into pattern? It's something which I encounter very often. It's kind of like out parameters where you can also reuse existing variables instead of declaring new ones. In my opinion it's something which keeps pattern matching from being as expressive as it could be.

A simple example where into would be very useful:

public bool TryConvertToInt(object originalValue, out int intValue)
    => originalValue is int into intValue || (originalValue is string str && int.TryParse(str, out intValue));

Maybe I am missing something, but right now I would do it the following way:

public bool TryConvertToInt(object originalValue, out int intValue)
{
    if (originalValue is int iv)
    {
        intValue = iv;
        return true;
    }

    return originalValue is string str && int.TryParse(str, out intValue);
}

[333fred]

Consider a when clause after a pattern with an into: what happens if the pattern matches, but the when does not?

[Phantonia]

I can see the problem. At first I thought that this should be similar to out parameters, as in:

int x = 4;

if (int.TryParse("5", out x) && x < 3)
{ }
else
{
    // x == 5
}

So:

string s = "abc";
object o = "xyz";

switch (o)
{
    case string into s when s.Length >= 4:
        break;
    default:
        // s == "xyz"
        break;
}

But I can see how that would be counter intuitive. In this example, s == "abc" in the default branch seems more reasonable.

The way I would solve this is creating a temporary variable and assigning it the value of s right before the type check is performed and, in case the when condition is false, assign the value of this temporary variable back to s.

The code could be equivalent to this then:

string s = "abc";
object o = "xyz";

string temp = s;
s = o as string;

if (s != null && s.Length >= 4)
{ }
else
{
    s = temp;
    // s == "abc"
}

It's still up to debate which behaviour would be more intuitive.