C# 3.0 represents a radical new approach to .NET development. The new language features were added primarily to support Language Integrated Query (LINQ), allowing you to query data using the same constructs regardless of where the data is currently stored. However, you'll find that there are many things you can do with these new features outside of queries. There's a learning curve for these new features, but by adopting them you'll find that you can be much more productive than you ever were in earlier versions of C#. In this article, I'll give you a whirlwind tour of C# 3.0 language features, and how you can leverage them in your work. After that I'll discuss the LINQ project and show you how these features are used to build LINQ. You'll see that they are simpler, more concise syntax for constructs you already use today. That will give you a big start up that learning curve.

Implicit Properties
The simplest feature is Implicit Properties. Implicit Properties are a shorthand notation to create a property with a backing field. In earlier versions of C#, you would write:

private string name;

public string Name
{
    get { return name; }
    set { name = value; }
}

Now you can write this more concise version:

public string Name
{
    get;
    set;
}

You can combine implicit properties with property access modifiers to create read-only properties:

public string Name

{
    get;
    private set;
}

This syntax means that the class can modify the Name property, and all types can view the value of the Name property. The only drawback to implicit properties is that you can't access the compiler-generated field, even in your own class. In practice, that's rarely an issue because the JIT compiler will, in all likelihood, inline the Property Set Accessor and your type's code will directly access the compiler-generated backing field anyway.

The simplified syntax for implicit properties makes it easier for you to create classes that follow the recommended best practice of using properties instead of publicly accessible fields. Using an implicit property is no more work than creating a publicly accessible field. And, if you find that later you need more logic in your property accessors, you can add that in a way that is binary-compatible for your users. You replace the implicit property with an explicit property, add an explicit backing field, and add your custom logic. The public interface to your type remains the same. None of the clients of your component need any changes, or even a recompile.

Of course, there are some limitations to using the new implicit property syntax. Most notably, you can't enforce immutable types when you rely on implicit properties. The implicit backing field isn't read-only in the current type, and your private Set Accessor can be called from any method in the type.

Partial Methods
Next, we'll discuss partial methods. You'll likely only run into partial methods when you're extending wizard-generated code. Partial methods were added to provide for extensibility hooks in partial classes. It's best explained by example. Suppose I wrote the following generated class to protect a precious resource:

public partial class Smeagol
{
   private readonly object myPrecious;

   public Smeagol (object somePreciousResource)
   {
     myPrecious = somePreciousResource;
   }

   public object MyPrecious
   {
     get { return myPrecious; }
   }
}

It's a partial class because developers may want to add functionality to the generated code. However, developers may also want to intercede and do something different when the precious resource gets accessed. I can add that capability using partial methods. First, I declare a partial method that can be called from the generated code:

partial void BeforeAccessingPrecious();

Next, I call the method wherever it's appropriate:

public object MyPrecious

{
   get
   {
     BeforeAccessingPrecious();
     return myPrecious;
   }
}