With nullable value types like int?, add automatic unwrapping if the valaue isn't null

[WillPittenger]

Currently, with a type like string?, you can use the following to test for null:

string? value = something;
if(value != null)
  value; // Do something with value as it isn't null and is safe to access

But with a value type like int?, you need a different syntax:

int? value = something;
if(value.HasValue)
  value.Value; // The value is non-null and value.Value holds the value.

It'd be much better if nullable value types could use the first syntax. The compiler would then map that to the second if needed.

[HaloFour]

You can already use if (value != null) to test an nullable value type.

As for the Value property, that's necessary as nullable value types are a different type from the actual value type, e.g. Nullable<int> vs. int. Silently treating the nullable value type as the value type would create ambiguities, particularly where the value type it wrapped also had a property called Value.

[WillPittenger]

In the case of a conflicting property, the compiler would attempt to use the one from the value type, in this case int.

[HaloFour]

That's what makes it ambiguous. This has been suggested before but the language team was not interested in introducing such an ambiguity. I do not have a link to the other discussion off-hand at the moment.

[HaloFour]

Here's some discussions on the subject:

#1865
#4647

[TahirAhmadov]

I think if we were doing everything from scratch, it could potentially be possible to drop the .Value dereferencing. But at this point, given the legacy of existing code, it's downright impossible.