Why is variable declared with "declaration pattern" only available in if statement

Question

For reference in this example I have this Person type, although it could be any type:

public class Person
{
   public Person? Partner { get; set; }
   public Person? Child { get; set; }
}

Somewhere else I am checking if the person has a partner and children, but its not required to assign either.

Currently it looks like:

Person partner = null!;
if (person.Partner is not null)
{
   partner = person.Partner;
   //do stuff
}

if (person.Child is Person child)
{
   if (partner is not null)
   {
      //do one way
   }
   else
   {
      //do other way
   }
   //do stuff
}

Live example

I wanted it to look something along the lines:

if (person.Partner is Person partner)
{
   //do stuff
}

if (person.Child is Person child)
{
   if (partner is not null)
   {
      //use partner
   }
   //other stuff
}

Live Example

partner on the last example is considered declared outside of the if statement scope, but is not assigned. How could I, using this pattern, let the compiler know that its either assigned with the person.Partner reference or null!?

Much like the out keyword on the following example doesn't throw a "not assigned" error:

SomeMethod(out Person partner);
if(partner is not null) { }

Live Example

I am learning about the C# patterns and have looked into the documentation and feature proposal and there is no mention of what I was looking for, not even why it is declared outside of the scope preventing me from using the variable name? Even if I tricked my way around the pattern using it on the needed scope as shown here its not assigned.

Is the above first example the standard approach and only way to do it?

Answer 1

The behavior you're seeing is very intentional, because it helps to treat variables like this in many, many cases where you only want to deal with a non-null value.

The decision to treat the variable as unassigned outside of the if statement is easy to explain: since a variable declared this way is inherently not null, you wouldn't want to allow its use in a place where it could be null. This provides compile-time safety to prevent people making a common mistake.

One could certainly argue that there's precedent for moving the variable scope inside the if block, similar to what happens with variables declared in a for statement's initializer. Perhaps the language designers felt the principle of least surprise was best served by preventing the reuse of variable names where the scopes might be ambiguous. C-based languages have for loop behaviors long before C# came along, whereas pattern matching is a new feature. It's also reasonable to imagine non-nested for loops are less logically coupled to one another, whereas if conditionals are more frequently used for control flow decisions that might be related to one another:

// A common pattern: we see these as two distinct steps.
for(int i = 0; i < someValue; i++)
{
  ...
}
for(int i = 0; i < someOtherValue; i++)
{
  ...
}

// This could be more confusing: 
// better to name the variables `parentPartner` and `childPartner`.
if(parent.Partner is Person partner)
{
  ...
}
else if(child.Partner is Person partner)
{
  ...
}

This decision also enables patterns like the following:

if (child.Parent is { IsLiving: true } responsiblePerson)
{
    Console.WriteLine("Child has a living parent to be their guardian");
}
else
{
    Console.WriteLine("Child is a ward of the state");
    responsiblePerson = theState;
}
// use `responsiblePerson` here.

If you're annoyed by the verbosity of your first solution, why not try this?

Person? partner = person.Partner;
if (partner is not null)
{
   // do stuff: the compiler will recognize `partner` is not null here
}

if (person.Child is Person child)
{
   if (partner is not null)
   {
      //do one way
   }
   else
   {
      //do other way
   }
   //do stuff
}

Answer 2

I would argue that @StriplingWarrior answer covers the question itself but I would like to point several things out:

Currently it looks like: ...

I would say that correct variable declaration should look like:

Person? partner = null;

So the nullability info is represented correctly.

or even better just:

Person? partner = person.Partner;

and compiler will understand that:

if(partner is not null)
{
    Console.WriteLine(partner.SomeProp); // partner is not null here, no warnings
}

Much like the out keyword on the following example doesn't throw a "not assigned" error: ...

I would argue that this is an incorrect comparison, in case of out keyword the out parameter should be explicitly assigned some value (ideally a valid one, respecting the nullability info), i.e.:

void SomeMethod(out Person partner)
{
    partner = new Person();
}

Which obviously is not supported by the pattern matching (and syntax to support that potentially can be quite cumbersome).

Since C# does not automatically initialize local variables (i.e. Person p; can be used until assigned some value, see this answer why) you see the error.

P.S.

There is also option to use empty property pattern for null checks {} (see this answer):

if (person.Partner is {} partner)
{
   //do stuff
}