Feedback on "Property pattern" discussion

[q42jaap]

In https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-04-30.md property patterns are discussed.

I personally prefer the : colon option, it feels a lot like it's done in ES2015 (https://babeljs.io/learn-es2015/#destructuring), even it is matching instead of assigning.

I think pattern matching should look like named destructuring (hope that this will be in scope):

{ Name: var name, Employer: { ID: var id } } = student;

The matching also has some destructuring inside it, as shown in the Future of C# talk on Build 2018.

[alrz]

{ Name: var name, Employer: { ID: var id } } = student;

What should happen when student or student.Employer is null? throw?

In ES we can provide a default value, I don't know if that'd be useful in C#.

[HaloFour]

@alrz

What should happen when student or student.Employer is null? throw?

IMHO deconstruction like this only really belongs in the context of pattern matching. I'd think that the ratio of scenarios in which the compiler could guarantee that the deconstruction would succeed would be relatively low.

[q42jaap]

Thanks for you feedback, I knew it would be a bad idea 😉

[q42jaap]

@alrz Doesn't the problem of nulls also occur in Tuple deconstruction?

[alrz]

No, because those are value types and cannot be null. see you can't deconstruct a (int, int)?, for instance.

[alrz]

Note that if you define Deconstruct on a reference type, it'll throw on null (which is not any better than this scenario)

I suggest you keep this open because imo it might come in handy actually if you don't have a Deconstruct.

--

PS: I think this could be a fine alternative to separate assignments sometimes,

var [a, b] = array;

var a = array[0];
var b = array[1];

var [.., last] = array;

var last = array[^1];

var { Name: name, Age: age } = GetPerson();

var p = GetPerson();
var name = p.Name;
var age = p.Age;

var {[key1]: value1, [key2]: value2 } = GetDictionary();

var d = GetDictionary();
var value1 = d[key1];
var value2 = d[key2];

Note: the lhs is not a pattern perse, it's just an extended deconstruction syntax i.e we're not "matching" we're deconstructing. so no patterns (like constants) should be allowed instead of names (just like ES).

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

[mpawelski]

Quite old issue but since it's in "Discussion" I'll add my two cents.
I really like this comment from another pattern matching issue:

I really think that one of the overall goals of putting patterns into C# should be construction/deconstruction symmetry.

I'm mostly familiar with pattern matching in F# and there the syntax shows much cleared symmetry between construction and deconstruction:

type Bar = {
    PropBar: int
}
type Foo = {
    Prop1: string;
    Bar: Bar
} 
let foo1 = { Prop1 = "test1"; Bar = { PropBar = 1} }
let matchTest1 = 
    match bar with
    | { Prop1 = "test1" } -> "test"
    | { Prop1 = "test2"; Bar = { PropBar = b} } -> "test_" + (string b)
    | _ -> "default"

just notice that construction of Foo record is almost the same as deconstruction.
Even cool deconstruction syntax mentioned by @alrz is what F# have (another example that C# should try to copy nice stuff from this language ;-)):

let { Bar = { PropBar = extractedPropBar }} = foo1
printfn "%d" extractedPropBar

However when we code in C# this doesn't look that similar:

public class Bar
{
    public int PropBar { get; set; }
    public Point Position { get; set; }
}
public class Foo
{
    public string Prop1 { get; set; }
    public Bar Bar { get; set; }
}
public class Point
{
    public int X { get; }
    public int Y { get; }
    public Point(int x, int y) => (X, Y) = (x, y);
    public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);
}

...

var foo1 = new Foo { Prop1 = "test1", Bar = new Bar { PropBar = 1, Position = new Point(2, 4) } };
var foo2 = new Foo { Prop1 = "test1", Bar = new Bar { PropBar = 2 } };
object foo2obj = new Foo { Prop1 = "test5", Bar = new Bar { PropBar = 5 } };

var testMatch = foo1 switch
{
    { Prop1: "test1", Bar: { PropBar: 1, Position: (2, 3) } } => $"test_{1}_p_",
    Foo { Prop1: "test1", Bar: Bar { PropBar: 1, Position: Point(2, 4) } } => $"test_{1}_p_",
    { Prop1: "test1", Bar: { PropBar: 1, Position: (_, var y) } } => $"test_{1}_py_{y}",
    { Prop1: "test1", Bar: { PropBar: var b } } => $"test_{b}",
    _ => "default"
};

I really like the current syntax for pattern matching and I think it should stay like that. But it would be great if in future we could get new syntax for constructing object that would use : instead of =. This new syntax would be valuable in itself because it would get us what target-typed new feature wanted to provide us - a clean syntax that allows us to omit type name when it can get inferred. Here is the hypothetical example how we could create previous objects:

Foo foo1a = { Prop1: "test1", Bar: { PropBar: 1, Position: (2, 4) } };
var foo1b = Foo { Prop1: "test1", Bar: Bar { PropBar: 1, Position: Point(2, 4) } };

The new keyword is not used in this syntax version and type name is optional (just like when doing "property pattern" of a type). It is assumed that you call default constructor, or the one that match "tuple pattern". In future it could work with record types if we ever get there. We should also probably think also about adding collection and index initializes but I think there are other issues that discuss it how pattern matching would look for those. The main goal here is to have have two things:

1. symmetry between construction of object and deconstruction in pattern matching
2. handle scenarios that target-typed new feature supposed to do

[Stamo-Gochev]

Are there any discussions going on about this proposal? Or any update? The original proposal for:

{ Name: var name, Employer: { ID: var id } } = student;

in the case where "Employer" is null can return the default value for the type of "ID" (it can be null if it is int?).

The idea for arrays is also helpful:

var [a, b] = array;

This might be trickier when the array has only 1 element - using a[1] throws an exception, so probably this should throw as well.

@MadsTorgersen

[HaloFour]

@Stamo-Gochev

Recursive property patterns are shipping in C# 8.0 which is feature complete. The pattern you specified for Employee will only match if that property is not null, but ID can be null, depending on the data type.