Behavior of "var" quickinfo and nullable reference types

[ryzngard]

We have had a few reports spread across feedback tools. I'd like to create a specific issue to track the discussion and user impact. This is strongly related to discussion in #53078 and user feedbacks such as https://developercommunity.visualstudio.com/t/Incorrect-type-deduction-tooltip-for-var/

This is specifically on why we show string? in cases where using var is assigned from a string value. For example:

var x = "Split";
var splitString = x.ToString();

This does not apply only to string, but any reference type assignment. Current IDE behavior is captured below:

A few important things about this issue:

1. Method Returns string[] But var types as string[]? #53078 does a great job of the discussion on why the behavior exists, and the thought put into this as it adheres to language design. This is not a proposal to change the language design here, but rather how we as a tooling team can help users understand the design better.
2. This will be a good issue for tracking any confusion/feature requests in this area. That way we can gauge user interest in wanting this feature for prioritization.

I will mark this as "Needs Proposal" to signify that there is not a clear design moving forward, and we will see track closely user feedback to help us prioritizing coming up with a design to help users.

[jasonmalinowski]

So even though I understand the underlying language design and why we did it that way, I still get thrown off on occasion by this. I wonder if it's worth adding a little bit of text to quick info that says something like "The thing assigned to the var was string" in the example above, so it's clear that the return type here isn't necessarily what people think it is.

[Vannevelj]

I filed a feedback item around this. It particularly confuses me combined with inlay hints: I love them, as well as var and NRT, but combine them and I feel like I'm constantly questioning my code.

e.g. in this screenshot, both variables are guaranteed non-null:

[CyrusNajmabadi]

I personally think the inline-hints display is not only accurate, but desirable. It's good to know that objectSymbol is an INamedTypeSymbol? as i can, and should, be able to assign null to it.

I agree that QI could have additional text saying something akin to "known to be non-null at this point in te program" or somethingl ike that.

[jasonmalinowski]

@ryzngard Hmm, I would have expected the flow analysis to be shown though in your screenshot...it would have at a later use, right?

[jasonmalinowski]

It's good to know that objectSymbol is an INamedTypeSymbol? as i can, and should, be able to assign null to it.

I actually hate it -- I'm more likely to read that variable than write to it (at least in the sense that all variables are read, but not all written to) and it's now telling me I have to be careful before access. I can mouse over it, but that defeated the whole point of the inline hint.

[ryzngard]

@ryzngard Hmm, I would have expected the flow analysis to be shown though in your screenshot...it would have at a later use, right?

Not sure I follow. Did you want to see what flow analysis says on x.ToString()?

The code and gif are aligned. There's no usage after that or other assignments.

[CyrusNajmabadi]

i mean, you do have to be careful before access. unless at the access point we've proven it is non-null. but at that point we'll test and tell you if there's a problem. :)

[CyrusNajmabadi]

@jasonmalinowski i think this is because this is a decalration point, not a reference point.

[Vannevelj]

I would expect objectSymbol to be annotated as INamedTypeSymbol as long as it only has non-null assignments. The moment we do assign a value that might be null, then the inlay hint can be updated to the broader type. But as long as that doesn't happen, I want to see as narrow a type as we can guarantee.

If I have to choose between "knowing a variable with nullable type hint is actually non-null" and "knowing a non-null variable can be widened to nullable", I choose the latter. The latter is one-time knowledge that will set me up for any scenario in which I encounter this. The former is something I have to check every single time

[sharwell]

I'm also in favor of the current approach, primarily because that is the true static type of the variable and it's the only type of the variable according to the compiler. Changing it based on the assignment characteristics means we're reimplementing the nullable walker with intentional deviation from the actual nullable walker.

[CyrusNajmabadi]

I would expect objectSymbol to be annotated as INamedTypeSymbol as long as it only has non-null assignments. The moment we do assign a value that might be null, then the inlay hint can be updated to the broader type. But as long as that doesn't happen, I want to see as narrow a type as we can guarantee.

This is not the view of the language, and it seems outright misleading. e.g. if something says "i am not null" then i should nto be able to assign null to it :)