var? keyword

[aobatact]

var? keyword might be useful when we introduce nullable reference types.
For example

string NonNullableMethod() => "Hello";
string? NullableMethod()=> null;

var x = NonNullableMethod(); // string
var y = NullableMethod(); // string?
var? z = NonNullableMethod(); // string?

It might be useful for nullable struct too.

struct LongNameStruct{}

var? x = new LongNameStruct();

insted of

LongNameStruct? x  = new LongNameStruct();

[Joe4evr]

The current idea is that var propogates the null-ness of what gets assigned to it. And are you really ever going to assign a new local variable and set it to null later? I can't think of any time when that would be useful.

I'm also not sure how I feel about the other example, because that declaration would then all of a sudden become a Nullable<T>, violating the Principal of Least Surprise (and again, I see literally zero reason to manually set a local to null after it's already been created).

[MgSam]

And are you really ever going to assign a new local variable and set it to null later? I can't think of any time when that would be useful.

This is probably reasonably common. Any time you're re-using a variable in a potentially complicated method and want to clear it out at some point (if some condition gets met, for example).

[HaloFour]

Hm, even if the compiler always treated the reference type inferred as nullable the compiler should still be able to determine it's actual nullness based on flow analysis. So it makes sense for var to always be nullable when it comes to reference types. If you assign it the result of a non-null expression the compiler would treat that as non-null until the point that the variable is assigned something else.

string ReturnsNonNullable() => "Hello";
string? ReturnsNullable() => "World";

var s = ReturnsNonNull(); // is string? but is definitely not null
if (s.Length > 0) { ... } // no warning, s is not null here

s = ReturnsNullable(); // legal, s is nullable
if (s.Length > 0) { ... } // warning, s might be null here

s = null; // legal, s is nullable

I guess it depends on if it's considered more important to guard the value of s at the time of assignment v. at the time of consumption.

[alrz]

it makes sense for var to always be nullable when it comes to reference types.

I think not. If I opted into non-nullable references, I want to get a warning at s = ReturnsNullable(); otherwise it nullifies the purpose of being non-nullable.

[HaloFour]

@alrz

Why? Assignment to a local is irrelevant if you don't do anything with that local and if you get the warning at any attempt to use that local then non-nullable references would still be doing it's job.

I'm not really arguing one way or another, just trying to understand the arguments. Since non-nullable references aren't types but only hints to usage and a specific variable may switch between nullable and non-nullable due to flow analysis (when declared as nullable) then the requirement of var specifically propagating nullability seems a lot less necessary. If s were something that could escape the method, like a ref/out parameter or a field then I would wholeheartedly agree with you, but those need to be explicitly defined and type inference does not apply.

[HaloFour]

@alrz

I've also copied my original comment here as I think it's more relevant to that thread.

[jjvanzon]

@HaloFour

Once this null analysis takes off, people might see it as more than a subtle hint, but rather the replacement of the null-handling in their code.

Using var or not using var is way too trivial and should not change the null-safety of your code.

[alrz]

@HaloFour

I see where you're going with this. To be fair, that makes it easier to adopt. At the local level you should mainly depend on static analysis as a consumer of ? hints. This is exactly how R# annotations work today, just that ? syntax here makes it easier to annotate types and specifically type arguments.

[orthoxerox]

I agree with @alrz that C# should infer the type as non-nullable whenever possible. Otherwise these two snippets will get different treatment from the compiler:

var foo = GetFooAlways(); //typed as Foo?
AcceptFooNotNull(foo); //warning, expected Foo, but got Foo?

AcceptFooNotNull(GetFooAlways()); //no warning

Yes, flow analysis might infer that foo is never null, but if it can infer that, why not encode that?

[alrz]

@orthoxerox

That was my first impression too. But you should not look at string? as a "type" like Nullable<T>. it's just an annotated type, so encoding it at local level doesn't make much sense since we're using static analysis all the way.

In that example foo is not "typed" as Foo? -- it's just allowed to be null, but we know that it's definitely not null at that particular point. the compiler can figure any null dereference afterwards. So neither of your examples would produce a warning.