Out variables in C# 7.0

C# 7.0 brings some features to out variables. These new features help us write cleaner code and handle out variables better. This blog post provides samples of these new features in C# 7.0 and as a surprise it also demonstrates what compiler is doing with these new features.

Inline out variables

Let’s start with piece of code that demonstrates how TryParse() and some TrySomethingElse() methods work.

var intString = "1111";
int i = 0;
 
if(int.TryParse(intString, out i))
{
    // it's integer
}
else
{
    // it's not integer
}

The code above uses out variable i that needs to be declared before TryParse() method is called. In case of method with more out variables we have to declare all these variables before calling the method. Imagine three out variables of different type, by example.

C# 7.0 allows us define out variables inline. The previous code can be written this way.

var intString = "1111";
 
if(int.TryParse(intString, out int i))
{
    // it's integer
}
else
{
    // it's not integer
}

NB! Use this trick if you are using out variable near where it is defined. If you need this variable also in other blocks that follow the declaring block then better go with traditional out variable.

Using var

But we don’t have to specify the type of out variable directly. Compiler can find it for us and this means we can also go with var. The next piece of code is the same as previous one.

var intString = "1111";
 
if(int.TryParse(intString, out var i))
{
    // it's integer
}
else
{
    // it's not integer
}

NB! Here loose nothing when using var as it is easy to see that out type will be int. For other methods with out variables like those you can find when using P/Invoke need actual type to be written out if the same line doesn’t communicate it clearly.

Skipping out variable

Sometimes we don’t need out variable at all. Good example is removing elements from concurrent dictionary. Here is the fragment of code from my ASP.NET Core WebSocket chat room example. In WebSocket middleware class I have to remove the instance of socket from concurrent dictionary _sockets.

WebSocket dummy;
_sockets.TryRemove(socketId, out dummy);
 
await currentSocket.CloseAsync(WebSocketCloseStatus.NormalClosure, "Closing", ct);
currentSocket.Dispose();

When removing the socket I’m not interested of getting the instanceof it  because I already have it. On C# 7.0 we can skip out variable by replacing it with underscore.

_sockets.TryRemove(socketId, out _);

NB! ConcurrectDictionary<T,U> has TryRemove() method like this for certain reasons and it is not design flaw.

Using out variable skipping we can easily write code to check if string value can be turned to integer or not.

if(int.TryParse(intString, out _))
{
    // it's integer
}

Behind the compiler

Let’s take a look what compiler actually produces if we build method that uses out variable skipping. Here is the method:

static void Main(string[] args)
{
    var intString = "1111";
 
    if(int.TryParse(intString, out _))
    {
        // it's integer
    }
    else
    {
        // it's not integer
    }
 
    Console.ReadLine();
}

Now let’s build the program and open resulting DLL in JetBrains dotPeek.

private static void Main(string[] args)
{
    int result;
    if (!int.TryParse("1111", out result))
        ;
    Console.ReadLine();
}

We get straight back to the roots.

Wrapping up

Out variables that are used in same block with TrySomething() method can now be declared inline where these variables are used in method call. Also keyword var is supported. Inline declarations of out variables lead us to cleaner code but we may loose readibility if these out variables are used also in other code blocks. Out variable skipping is good option when we don’t care about value of out variable. Like with everything else in coding there is one suggestion: use these features carefully and only if you benefit something from them.