Update 20th October 2015: As Karl Fenech pointed out, this feature has been dropped in the final version of C# 6.0.

Up until C# 5, you couldn’t have a parameterless constructor in a struct. So if you try something like this:

    public struct Point
    {
        public int x;
        public int y;

        public Point()
        {
            this.x = 0;
            this.y = 0;
        }

        public Point(int x, int y)
        {
            this.x = x;
            this.y = y;
        }
    }

…then it’s not quite going to work:

At the time of writing this article, using a parameterless constructor in a struct as above is now supported, but as an experimental feature. This means you need to edit your project’s .csproj file and add the Experimental language version as shown below:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>AnyCPU</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
    <LangVersion>Experimental</LangVersion>
  </PropertyGroup>

Parameterless struct constructors still require you to initialise all members of the struct, just like any other struct constructor.

Additionally, parameterless struct constructors must be public:

The reason for this is explained in the C# Design Notes for Aug 27, 2014:

C#, VB and F# will all call an accessible parameterless constructor if they find one. If there is one, but it is not accessible, C# and VB will backfill default(T) instead. (F# will complain.)

It is problematic to have successful but different behavior of new S() depending on where you are in the code. To minimize this issue, we should make it so that explicit parameterless constructors have to be public. That way, if you want to replace the “default behavior” you do it everywhere.

We already have the ability to branch our exception-handling code depending on the type of exception, by using multiple catch blocks:

            try
            {
                Console.WriteLine("Enter a number");
                string inputStr = Console.ReadLine();
                int input = Convert.ToInt32(inputStr);
                Console.WriteLine(5 / input);
            }
            catch(FormatException ex)
            {
                Console.WriteLine("Input must be a number");
            }
            catch(DivideByZeroException ex)
            {
                Console.WriteLine("Can't divide by zero");
            }
            catch(Exception ex)
            {
                Console.WriteLine("Doh");
            }

In C# 6, we will be able to filter exceptions by handling them only if a condition is true. For example, we may want special treatment for exceptions that have an InnerException:

        static void Main(string[] args)
        {
            try
            {
                throw new InvalidOperationException("Invalid operation",
                    new Exception("Justin Bieber is breathing"));
            }
            catch(Exception ex) if (ex.InnerException != null)
            {
                Console.WriteLine(ex.Message);
                Console.WriteLine("  -->{0}", ex.InnerException.Message);
            }
            catch(Exception ex)
            {
                Console.WriteLine(ex);
            }

            Console.ReadLine();
        }

An additional benefit of exception filters is described in the C# feature descriptions (PDF):

Exception filters are preferable to catching and rethrowing because they leave the stack unharmed. If the exception later causes the stack to be dumped, you can see where it originally came from, rather than just the last place it was rethrown.

The same PDF also describes a method to take advantage of the conditional expressions used in exception filters in order to perform some action that uses but does not actually handle the exception. The description and code below are taken from that PDF.

It is also a common and accepted form of “abuse” to use exception filters for side effects; e.g. logging. They can inspect an exception “flying by” without intercepting its course. In those cases, the filter will often be a call to a false-returning helper function which executes the side effects:

private static bool Log(Exception e) { /* log it */ ; return false; }
…
try { … } catch (Exception e) if (Log(e)) {}

The safe navigation operator, first announced and described in this blog post, has been available since the first Visual Studio 14 CTP due to its popularity in Visual Studio User Voice..

The operator, written as ?. in code, has been referred to by many names: safe navigation, null-conditional, null propagation, and conditional access are the ones I’ve come across so far.

Just to demonstrate the concept in an extremely simple manner, consider the following code:

            List<string> list = null;
            int count = list.Count;

It’s pretty obvious that if you try to run the above code, you’re going to get a NullReferenceException, because you’re trying to access the Count property of an object that is null.

Now, the example above can seem dumb because it’s pretty obvious that the list is null, but sometimes objects can come from external sources or user input, and so you have to be careful how you handle them. In this case we can work defensively by adding a null check:

            List<string> list = null;
            if (list != null)
            {
                int count = list.Count;
            }

That’s okay. But it can get pretty messy when there is a chain of references involved. Consider a binary tree, for instance.

var something = binaryTree1.LeftChild.LeftChild.Name;

If we were to write defensive conditionals for this, you effectively need a null check for each access.

            List<string> list = null;
            int? count = list?.Count;

The use of the safe navigation operator involves putting a question mark before the dot operator, as shown above. If list happens to be null (which it is in this case), then the Count property is not accessed, and null is immediately returned. Since list?.Count may return either a number or null, the count variable must now be nullable.

The safe navigation operator pays off pretty nicely when you have more complex reference accesses:

var something = binaryTree1?.LeftChild?.LeftChild?.Name;

It also works pretty nicely with the null-coalescing operator.

            List<string> list = null;
            int count = list?.Count ?? 0;

We can even use it to guard access to array elements when the array is null:

            string[] names = null;
            int length = names?[1].Length ?? 0;

…or guard access to array elements which may themselves be null:

            string[] names = new string[] { "Steve", null, "John" };
            int length = names[1]?.Length ?? 0;

The safe navigation operator is quite convenient in properties which make use of object instances. Consider the following property:

        public string SessionId
        {
            get
            {
                if (this.Session != null)
                    return this.Session.Id;
                else
                    return null;
            }
        }

We can now simplify this to:

        public string SessionId
        {
            get
            {
                return this.Session?.Id;
            }
        }

It’s also convenient to use the safe navigation operator to raise an event only if some delegate is subscribed to it. Consider an INotifyPropertyChanged implementation:

        public event PropertyChangedEventHandler PropertyChanged;

        // Create the OnPropertyChanged method to raise the event 
        protected void OnPropertyChanged(string name)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(name));
            }
        }

You can’t just stick in a ?. before the paranthesised argument list. So the recommended way to do this is by using the Invoke() method:

        public event PropertyChangedEventHandler PropertyChanged;

        // Create the OnPropertyChanged method to raise the event 
        protected void OnPropertyChanged(string name)
        {
            PropertyChangedEventHandler handler = PropertyChanged;

            handler?.Invoke(this, new PropertyChangedEventArgs(name));
        }

The safe navigation operator isn’t going to change our lives. But it’s one of those sweet syntactic sugar features that we’ll grow to love in time.