Simplified property pattern matching expression for nested properties

[julealgon]

Yesterday I stumbled upon a scenario where I needed to inspect a few properties on a given "response" object and respond to them accordingly. The problem was that some of the properties were nested multiple levels deep into the object graph, while others were in the root of the object.

This is an example:

return response switch
{
    { Authentication: { Status: not Success } } => DoSomething(),
    { Status: not Success } => DoSomethingElse(),
    { ContextData: { ApplicationData: { Check1: { Code: Blocked } } } } => DoAThirdThing(),
    { ContextData: { ApplicationData: { Check2: { Code: InvalidIdentificationDocument, Description: string message } } } } => DoAFourthThing(message),
    { ContextData: { ApplicationData: { Check2: { Code: InformationMismatch, Description: string message } } } } => DoAFifthThing(message),
    { ResponseInfo: { CurrentQueue: not null } } => DoASixthThing(),
    _ => DoDefault(),
};

As you can see, it becomes very unwieldy very fast when deep nesting levels are required in the matches.

I'd like to propose something like this instead:

return response switch
{
    { Authentication.Status: not Success } => DoSomething(),
    { Status: not Success } => DoSomethingElse(),
    { ContextData.ApplicationData.Check1.Code: Blocked } => DoAThirdThing(),
    { ContextData.ApplicationData.Check2: { Code: InvalidIdentificationDocument, Description: string message } } => DoAFourthThing(message),
    { ContextData.ApplicationData.Check2: { Code: InformationMismatch, Description: string message } } => DoAFifthThing(message),
    { ResponseInfo.CurrentQueue: not null } => DoASixthThing(),
    _ => DoDefault(),
};

At a first glance, it seems like an easy to implement syntactic sugar that doesn't appear to create any conflicts with existing language terms, as it relies on the . for navigation on something that doesn't support it today.

While incredibly convoluted, this example is actually closely based on a real use-case on my side, as I had to deal with several possible outcomes happening from a single external service response. I believe the service itself is not that well designed, but that's beside the point.

[CyrusNajmabadi]

This is not really the same though (though i can perceive how we could bend it to be the same). Specifically, ContextData: { ApplicationData: means ContextData is non-null, and yadda yadda. traditionally ContextData.ApplicationData would not mean hte same.

Now, we could consider that in a pattern context it would mean 'non-null'. I certainly think there is merit to this idea, and the savings are significant.

[CyrusNajmabadi]

Yup! I'm pretty solidly in the "this is a good idea, and these would be sensible and appropriate semantics here" :) I'm very busy right now. But i'll try to help move this to an actual proposal so we can see about moving forward with this. Thanks!

[CyrusNajmabadi]

Also, for me at least, i think the savings is not necessarily in characters. But around the actual difficulty in understanding the code and having the brain handle all the deep levels of nesting. So the value here is not that it's briefer. But rather that it's just much easier to both write and for people to then read and immediately understand what things mean :)

[julealgon]

Also, for me at least, i think the savings is not necessarily in characters. But around the actual difficulty in understanding the code and having the brain handle all the deep levels of nesting

Agreed. The nesting is what makes it harder for me to grasp it quickly as well.

[huoyaoyuan]

In my mind, ContextData.ApplicationData would mean non-null, where ContextData?.ApplicationData would mean nullable.

[alrz]

i'll try to help move this to an actual proposal so we can see about moving forward with this. Thanks!

🎉

[alrz]

Duplicate of #480

I think { Foo.Bar: pat } should be equivalent to { Foo: { Bar: pat } }. In the current form you don't get to choose to check nulls or not. It's always included.

That said, { Foo?.Bar: pat } would be no different than just simple member access syntax.

On the other hand, if you really want to consider ?. syntax then perhaps you want Foo.Bar to not check for nulls which is wrong. Patterns shouldn't throw in regular usage.

[alrz]

@CyrusNajmabadi

Are we going to accept { Foo.Bar: p, Foo.Bar: q }?

[julealgon]

Since { Foo { Bar: p, Bar: q } } is allowed today, I think it would be better for consistency to allow it as well right?

Either that, or it should be forbidden entirely.

[YairHalberstadt]

If this goes ahead we should probably do the same for object initializers:

var foo = new Foo
{ 
    Bar.Baz = { 1 ,2, 3},
    Goo.X = 42, 
};

Equivalent to:

var foo = new Foo
{ 
    Bar = { Baz = { 1 ,2, 3 } },
    Goo = { X = 42 } , 
};

Related is the (more complex) case of withers: #77