
# C# Language Design Meeting for Dec. 18, 2019

## Agenda

1. Nullable issues

    a. Pure null checks

    b. Consider `var?`

## Discussion

### Pure null checks

We have the following syntax which semantically check for null in the language:

* `e is null`
* `e == null`
* `e is {}`
* `e is object`

However, for nullability we have a separate notion of a "pure" null check that
causes a null branch to appear, even if the variable being tested was declared
not null, or vice versa.

An example of why this would matter is

```C#
var current = myLinkedList.Head; // assume Head is nullable oblivious/unannotated
while (current is object)
{
    ...
    current = current.Next; // assume oblivious
}
current.ToString(); // only warns if `is object` is a pure null test
```

We previously established that all "pure" null checks contain the word `null` in them, meaning
that only `e is null` and `e == null` are pure null checks today. There is a proposal that we
should unify all forms that are semantically equivalent, regardless of syntax.

There is also a proposal to expend this even to places which are not "pure" checks, i.e.
they have semantic effect larger than just checking for null. For instance, we could
also check `e is object o`, which also introduces a variable `o`. We came up with
the following list of potential checks:

```
e is null       // pure

e is object     // Proposed
e is [System.]Object // Proposed
e is object _
e is object x

s is string        // s denotes expr of static type string
s is string x
o is string x

e is {}          // Proposed
e is {} _
e is {} x

e == null       // pure
e != null       // pure

e is not null   // pure
e is not object // etc...
```

All parties argue that other positions are confusing as to why something is a pure
null check and something else, that's very similar, is not. It seems like drawing
any particular line will always imply that something similar could be confusing.

One difference between versions that check between a semantically pure null check, i.e. a piece
of syntax that has no other meaning than testing for null, is that if there is a pure null check
then any warning is definitely a bug in user code: either the check is superfluous, or there is
an actual safety issue. If the check is not pure, there may not be a bug, because the check may
not actually be superfluous and this may be a spurious warning.

Given that the pure null checking is useful, it's mainly about finding the right balance between
helping the user find bugs in their code and finding a set of rules that are also easily
understandable. The main argument against broadening beyond our current rule is that "pure checks
contain the word 'null'" is a simple rule, and adding warnings in an update is a heavy way to
address the issue.

On the other hand, we have changed nullable warnings multiple times already, plan to
do it again, and have warned people that nullable warnings may be in flux for a time.
If the feature is also meant to react to user intent, and if we believe `x is object`
is intended by the user to be a null check, then making it a pure null check would
be correctly responding to user intent.

We could also decide based on whether or not we want to suppress certain patterns. If
we believe `x is object` or `x is {}` aren't good ways to test for null, then making
them not pure null checks would encourage users not to use it. This did not seem a
compelling position for anyone in LDM.

**Conclusion**

We agree that we should broaden the set of pure null checks. We agree that `x is object` should
be a pure null check. Moreover this should be based on the type in the `is` expression, meaning
that any type `T` that binds to `System.Object` in `x is T` would be a pure null check. We also
agree that `x is {}` is a pure null check.

None of `x is object _`, `x is object o`, `x is {} _`, or `x is {} o` are pure null checks.

### `var?`

At this point we've seen a large amount of code that requires people spell out the
type instead of using var, because code may assign `null` later.

An example,

```C#
var current = myLinkedList.Head; // annotated not null
while (current is object)
{
    ...
    current = current.Next; // warning, Next is annotated nullable, but current is non-null
}
```

One way to deal with this is to allow `var?`,

```C#
var? current = myLinkedList.Head;
// now current is nullable, but the flow state is non-null
current.ToString(); // no warning, because the flow analysis says it's not null
```

This would let people express that the think the variable may be assigned null later on.

On the other hand, we could just permit these assignments when using `var`, and use flow analysis
to ensure safety.

```C#
var current = myLinkedList.Head;
current = null; // no warning because var is nullable
current.ToString(); // warning, the flow state says this may be null
```

This would allow users to be explicit when they want to make sure not to assign
null to a type, but they have to spell out the type.

**Conclusion**

Make `var` have a nullable annotated type and infer the flow type as normal.