[Proposal] null guards for nullable types

[mariusGundersen]

The following code does not compile:

        private int Test(int? value)
        {
            if (value != null)
            {
                return value + 5;
            }

            return 0;
        }

It should be clear to the compiler that inside the truthy branch of the if statement value is of type int, not int?, and that after the if statement it is null. This would be only of slight usage for the current nullable types, but with the next version of C# where everything can be nullable this would be of greater value.

This would be sugar for the following:

        private int Test(Nullable<int> value)
        {
            if (value != null)
            {
                int _value = value.Value;
                return _value + 5;
            }

            return 0;
        }

[HaloFour]

It would cause existing code to change semantics if the compiler would treat value as an int if that condition is true:

public void M(int? value) { ... }
public void M(int value) { ... }

public void Test(int? value) {
    if (value != null) {
        M(value);
    }
}

[mariusGundersen]

Yeah, I see your point. But that is a very strange use case though.

[bondsbw]

This could be more specific. When the return type is T, allow an implicit cast from T?. The result would be the same as explicit cast today (InvalidOperationException if null).

Flow analysis could provide a warning when it could be null.

[mariusGundersen]

@bondsbw you mean this case:

        private int Test(int? value)
        {
            if (value != null)
            {
                return _value;
            }

            return 0;
        }

Yes, that is probably less likely to break something

[Pzixel]

@mariusGundersen where are you taking it from? There is not _value variable so it's defentily doesn't compile unless there are some field _value which makes the whole example senseless.

[mariusGundersen]

sorry, yes, I meant this, which also does not compile because int? cannot be implicitly converted to int

        private int Test(int? value)
        {
            if (value != null)
            {
                return value;
            }

            return 0;
        }

[Pzixel]

@bondsbw why should it works for return values only? And what's about multithreading? If it's not a local for example:

    private int Test(MyValue value)
    {
        if (value.SomeField != null)
        {
            return value.SomeField;
        }

        return 0;
    }

what happens if another thread is changing the value between null check and return? If we limit its usage for locals only it becomes almost useless feature.

I don't think we need this. Unfortunly, we are not TypeScript developers where it works :)

If you don't want to write it twice you always can do:

    private int Test(int? value)
    {
        if (value is int result)
        {
            return result + 5;
        }

        return 0;
    }

I'd prefer operators to being working with null propagation (as method calls, for example):

    private int Test(int? value) => value?.+(5) ?? 0;

which is the equivalent of:

    private int Test(int? value) => value?.Add(5) ?? 0;

[bondsbw]

@Pzixel

why should it works for return values only?

If implicit casting can work for other cases without running into the problems @HaloFour pointed out, I would agree with considering those cases.

what happens if another thread is changing the value between null check and return?

This was discussed in another thread related to nullability flow analysis. I believe the idea is that the feature is useful even if it's not perfect (and it should not be advertised as perfect).