C# 9.0 : Top Level Programs and Targeted type ‘new’ Expression

In the previous post, we saw how C# 9.0 introduced the init only properties. In this blog post, we will explore some more of the language features which would be introduced in C# 9.0.

Top Level Programs

One of the annonying quality of any programming language is the baggage of boiler plate code that needs to be written for trying out a one-line. For example, prior to C# 9, even hello word looks like following.

using System;

namespace CSharp9.TopLevelPrograms
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

That is plenty of boiler plate code for a simple hello world program. There was hardly any improvements in this regard, with the exception of static directive which was introduced in C# 6.

using static System.Console;

namespace CSharp9.TopLevelPrograms
{
    class Program
    {
        static void Main(string[] args)
        {
            WriteLine("Hello World!");
        }
    }
}

Even with that, there were plenty of boiler plate code. All that comes to an end with the introduction of Top Level Program. Yo could no do away with explicit Main and other boiler plate codes. Starting with C# 9, you could rewrite the above code as

using System;
Console.WriteLine("Hello World");

Or including the static directive

using static System.Console;
WriteLine("Hello World");

If you are trying out a new language feature, this would be highly useful. No longer do you need to all those unncessary boiler plate codes. Behind the scenes, nothing has changed, it is the same old Main which the compiler has generated.

// $Program
using System;

private static void $Main(string[] args)
{
	Console.WriteLine("Hello World");
}

The Top Level Programs are not limited to above, you could also write methods and classes. The methods gets converted to local methods. For example,

using static System.Console;
WriteLine($"Hello {GetName()}");
WriteLine($"Hello {new Foo().GetName()}");

string GetName() => "Anu Viswan";
class Foo
{
    public string GetName() => "Anu Viswan";
}

The above code gets converted to

using System;
using System.Runtime.CompilerServices;

[CompilerGenerated]
internal static class $Program
{
	private static void $Main(string[] args)
	{
		Console.WriteLine("Hello " + GetName());
		Console.WriteLine("Hello " + new Foo().GetName());
		static string GetName()
		{
			return "Anu Viswan";
		}
	}
}
internal class Foo
{
	public string GetName()
	{
		return "Anu Viswan";
	}
}


As you can see, behind the scenes, the compiler does all the magic to create the regular code, but enables the developers to write sample codes within minimum code.

Targeted Type ‘new’ Expression

How often have you wondered _what if, what if the compiler could detect the targeted type, without the developer having the mention it explicitly`. For example, consider the following code

public class Foo
{
    public string FirstName { get; set; }
    public string Get(Bar bar) => bar.UserName;  
}

public class Bar
{
    public string UserName { get; set; }
}

// client code
Dictionary<string, string> dictionary = new Dictionary<string,string>
            {
                ["Name1"] = "Anu Viswan",
                ["Name2"] = "Jia Anu"
            };
Foo foo = new Foo{ FirstName = nameof(Foo.FirstName) };
foo.Get(new Bar{ UserName = nameof(Bar.UserName) });

If you observe the client code, you could be left wondering

  • Why do you need to the Dictionary Type explicitly defined on Right Hand side when the assigned type has been defined.
  • Same is the case with the type Foo on second line of client code.
  • Why not omit the type when you know the method expects the particular type in the last line ? The compiler already knows that the method Get() accepts a parameter type of Bar.

All these are now answered by in C# 9.0 with the Targeted Type new expression. For example, now you could skip the duplicate types and omit the types when the types could be infered.

The above code could be rewritten as

Dictionary<string, string> dictionary = new()
            {
                ["Name1"] = "Anu Viswan",
                ["Name2"] = "Jia Anu"
            };
Foo foo = new (){ FirstName = nameof(Foo.FirstName) };
foo.Get(new() { UserName = nameof(Bar.UserName) });

Now isn’t that better. I am more excited about the last line, where you could skip the Type name if it could be inferred.

We will continue our exploration of the language features in upcoming posts.

Evolution of Properties : C# 1 to C# 9

Properties in .Net has evolved over time, retaining its core functionality while making it super sleek via subtle changes. Let us take a brief look at the evolution before digging in deeper about the features introduced in C# 9.

C# 1.0.

Back when it all started, if you were to declare a property in C#, you needed to write a lot of boiler plate code. For example, if you were to create a class to represent a person, it could be like

public class Person
{
    public string _firstName;
    public string _lastName;

    public string FirstName
    {
        get
        {
            return _firstName;
        }
        set
        {
            _firstName = value;
        }
    }

    public string LastName
    {
        get
        {
            return _lastName;
        }
        set
        {
             _lastName = value;
        }

    }
}

That was a lot of boiler plate code for something so simple with no extranous validation or execution of arbitary code. You had to declare backing up fields and manually declare getters/setters for each of the property.

C# 2.0

C# 2.0 didn’t make the life much easier, but it provided a significant improvement. It allowed us to write different access modifiers for getter and setter. For example,

public string _firstName;
public string FirstName
{
    get
    {
        return _firstName;
    }
    private set
    {
        _firstName = value;
    }
}

C# 3.0.

C# 3.0 brought the first significant improvement in property declation with the introduction of auto implemented properties. Now you no longer needed to declare backing fields(of course you could do it as well if needed). The Person class declared in the preceeding example could be now modified as following.

public class Person
{
    public string FirstName{get;set;}
    public string LastName{get;set;}
}

Compare that with the code we wrote in C# 1.0 and we realize how much cleaner the code looks now. Of course the compiler would generate the backing up fields behind the scenes, but as a developer that was a lot of ‘less’ code to write.

However, there was a major caveat still. The Auto implemented property syntax was restricted to read-write properties. You weren’t allowed to use the auto-implemented properties in the case of readonly properties, at least not yet. For Read-only properties, you were forced to write the backing fields still.

We could of course use the private accessor for the setter, but that wasn’t exactly readonly property. It would only restrict another class from changing the property, but it never constrains the class to change it within itself. For example,

public class Person
{
    public string FirstName{get;private set;}

    public void Foo()
    {
        FirstName = "Hey I can change you here";
    }
}

In other words, if you intend to create a imutable property which could be set only in the constructor, this approach didn’t quite work.

C# 6.0

Another problem with the private setter approach is that the intend is not clearly indicated. However, this got a major boost in C# 6, which allow us to skip the setter in the declaration, and there by making the intend more clear.

public string FirstName {get;}

It also ensured that we could now write the much desired immutable property pretty easily and with more concise code. That isn’t all with the improvements in C# 6 for properties. There was other improvements which go a long way in improving our exprience as developer.

Prior to C# 6, if you wanted to initialize the value of a Auto Implemented Property, you were forced to do it within a constructor (if the constructor was implicit, you are forced to make it explicit). For example,

public class Foo
{
    public string FirstName { get; set; }
    public Foo()
    {
        FirstName = "Initial Value";
    }
}

That’s way too verbose. Why would on want to introduce an explicit constructor, when you could have done it at point of declaration. However, the developers were deprieved of this feature till C# 6.0. With C# 6.0 and above, you could now do,

public class Foo
{
    public string FirstName { get; set; } = "Initial Value";
}

That is a lot more concise code. C# 6.0 also introduced Expression Bodied Members, which could be applied to properties as well. For example, if you want to have a Readonly Age property, which needs to be calculated from DateOfBirth, you could do so,

public class Foo
{

    public DateTime DateOfBirth { get; set; }
    public int Age => DateTime.Now.Year - DateOfBirth.Year;

}

C# 9.0

Dispite the improvements made to the one of the most basic functionality, there was still something lacking. In C# 3.0, Object initializers were introduced, which enabled us a new way to initialize properties at time of creation. For example,

public class Foo
{
    public string FirstName{get;set;}
    public string LastName{get;set;}
}

var foo = new Foo{
    FirstName = "Anu",
    LastName = "Viswan"
};

This freed the author of the class from writing all sorts of constructor, which was an alternative till then. However, there was something amiss here.

If your property is a immutable property, you cannot use object initialier syntax to initialize the value during creation. You would have to depend on a lot of boiler plate constructors. For example,

public class Foo
{
    public string FirstName { get; set; }
    public string LastName { get; }
}

var bar = new Foo
{
    FirstName = "Anu",
    LastName = "Viswan" // This throws an error
};

This problem was resolved in C# 9 with introduction of init only properties. The C# language designers introduced the initaccessor which could be only used with the initializers. For example, the above scenario could be rewritten as

public class Foo
{
    public string FirstName { get; set; }
    public string LastName { get; init; }
}
var foo = new Foo
{
    FirstName = "Anu",
    LastName = "Viswan" // This works !!!
};

init accessor is a variant of set, which works only with object initializers. As you can see, this is a small change, but it fills a void that was irritating for the developers.

That’s it for now.