Allow variable for "is not null" pattern

[hrumhurum]

Please take a look at the following code:

static Version? TryGetVersion() => new(1, 0);

if (TryGetVersion() is { } version)
    Console.WriteLine(version);
else
    Console.WriteLine("<null>");

It calls TryGetVersion() method and acts accordingly to its return value: the non-null values are propagated to the version variable and handled in corresponding code block; the null values are handled by another block.

The code does the job in a concise way but is ugly because { } construct is not self-evident IMHO.

The code below would produce a much more readable result immediately communicating the programmer's intent:

static Version? TryGetVersion() => new(1, 0);

if (TryGetVersion() is not null version)
    Console.WriteLine(version);
else
    Console.WriteLine("<null>");

Unfortunately, is not null pattern does not allow variables to be captured in the current preview version of C# language. Not sure if it's possible to allow that, but probably this is something to consider.

[yaakov-h]

#5788 (comment)

[iam3yal]

You can do if (TryGetVersion() is var version and not null).

[hrumhurum]

@eyalalonn, this looks pretty good. Not as concise as it could be but clearly does the job. Thank you for suggestion.

My personal vote goes to a bit different flavor because it reads more naturally:

if (TryGetVersion() is not null and var version)

[colejohnson66]

if (TryGetVersion() is Version version)

If you use the type name, you don't need the and not null check.

[Rekkonnect]

if (TryGetVersion() is Version version)

If you use the type name, you don't need the and not null check.

The point is to avoid using the type name, for it could be too long, or not as easily rememberable.

[burkenyo]

I would also find this a useful feature! The syntax:
if (invoke() is not null x)
is much more instantly recognizable than
if (invoke() is { } x)
and more concise than
if (invoke() is var x and not null)

[Rekkonnect]

I find this worthwhile adding in the language for the same reason we got the shorthand for { SomeString: { Length: 5 } } being { SomeString.Length: 5 }. It hurts just a little without that shorthand, but we did get it. The same applies here, where indeed null comparisons are more common than nested member evaluations in a pattern.