Jon Skeet: Coding Blog : C# 4, C#

The irritation of bad names

skeet — Wed, 27 Jan 2010 17:40:54 GMT

A couple of days ago I accidentally derailed the comments on Eric Lippert's blog post about unused "using" directives. The reason that redundant code doesn't generate a warning in Visual Studio is that it's what you get to start with in Visual Studio. This led me to rant somewhat about other aspects of Visual Studio's behaviour which sacrifice long term goodness in favour of short term efficiency. Almost all the subsequent comments (at the time of writing this post) are concerned with my rant rather than Eric's post. Some agree with me, some don't - but it's only now that I've spotted the bigger picture behind my annoyances.

All of them are to do with names and the defaults provided. I've blogged before about how hard it is to find a good name - it's a problem I run into time and time again, and the ability to rename something is one of the most important refactorings around.

If you don't know, ask

Now if it's hard to find a good name, it stands to reason that anything the IDE can generate automatically is likely to be a poor name... such as "Form1", "textBox1" or "button1_Click". And yet, in various situations, Visual Studio will happily generate such names, and it can sometimes be a small but significant pain to correct it.

The situation which causes me personally a lot of pain is copying a file. For C# in Depth, I have a lot of very small classes, each with a Main method. When I'm evolving an example, I often want to take the existing code and just change it slightly, but in a new file. So I might have a file called OrderByName.cs containing a class called OrderByName. (I agree this would normally be a bad class name, but in the context of a short but complete example it's okay.) I want to just select the file, hit copy and paste, and be asked for a new filename. The class within the file would then be renamed for me as well. As an aside, this is the behaviour Eclipse has in its Java tooling.

In reality, I'd end up with a new file called "Copy of OrderByName.cs", still containing a class called OrderByName. Renaming the file wouldn't offer to rename the class, as the filename wouldn't match the class name. Renaming the class by just changing it and then hitting Ctrl-. would also rename the original class, which is intensely annoying. You're basically stuck doing it manually with find and replace, as far as I can see. There may be some automated aid available, but at the very least it's non-obvious.

Now the question is: why would I ever want a file called "Copy of OrderByName.cs"? That's always going to be the wrong name, so why doesn't Visual Studio ask me for the right name? It could provide a default so I can skip through if I really want to (and probably an "Apply to all items" if I'm copying multiple files) but at least give me the chance to specify the right filename at the crucial point. Once it knows the right new filename before it's got a broken build, I would hope it would be easy to then apply the new name to the class too.

The underlying point is that if you absolutely have to have a name for something, and there's no way a sensible suggestion can be provided, the user should be consulted. I know there's a lot of discussion these days about not asking the user pointless questions, but this isn't a pointless question... at least when it comes to filenames.

If you don't need a name, don't use one

I'm not a UI person, so some of this section may be either outdated or at least only partially applicable. In particular, I believe WPF does a better job than the Windows Forms designer.

Names have two main purposes, in my view. They can provide semantic meaning to aid the reader, even if a name isn't strictly required (think of the "introduce local variable" refactoring) and they can be used for identification.

Now suppose I'm creating a label on a form. If I'm using the designer, I can probably see the text on the label - its meaning is obvious. I quite possibly don't have to refer to the label anywhere in code, unless I'm changing the value programmatically... so why does it need a name? If you really think it needs a name, is "label1" ever going to be the right name - the one you'd have come up with as the most meaningful one you could think of?

In the comments in Eric's blog, someone pointed out that being prompted for a name every time you dragged a control onto the designer would interrupt workflow... and I quite agree. Many of those controls won't need names. However, as soon as they do need a name, prompting for the name at that point (or just typing it into the property view) isn't nearly such a distraction... indeed, I'd suggest it's actually guiding the developer in question to crystallize their thoughts about the purpose of that control.

Conclusion

Okay, this has mostly been more ranting - but at least it's now on my blog, and I've been able to give a little bit more detail about the general problem I see in Visual Studio - a problem which leads to code containing utterly useless names.

The fundamental principle is that I want every name in my code to be a meaningful one. The IDE should use two approaches to help me with that goal:

Don't give a name to anything that doesn't deserve or need one
If a name is really necessary, and you can't guess it from the rest of the context, ask the user

I don't expect anything to change, but it's good to have it off my chest.

Type initialization changes in .NET 4.0

skeet — Tue, 26 Jan 2010 17:48:00 GMT

This morning, while checking out an email I'd received about my brain-teasers page, I discovered an interesting change to the CLR in .NET 4.0. At least, I think it's interesting. It's possible that different builds of the CLR have exhibited different behaviour for a while - I only have 32-bit versions of Windows installed, so that's what I'm looking at for this whole post. (Oh, and all testing was done under .NET 4.0b2 - it could still change before release.)

Note: to try any of this code, build in release mode. Running in the debugger or even running a debug build without the debugger may well affect the behaviour.

Precise initialization: static constructors

I've written before about static constructors in C# causing types to be initialized immediately before the type is first used, either by constructing an instance or referring to a static member. In other words, consider the following program:

using System;

class StaticConstructorType
{
    private static int x = Log();

    // Force "precise" initialization
    static StaticConstructorType() {}

    private static int Log()
    {
        Console.WriteLine("Type initialized");
        return 0;
    }

    public static void StaticMethod() {}
}

class StaticConstructorTest
{
    static void Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("No args");
        }
        else
        {
            StaticConstructorType.StaticMethod();
        }
    }
}

Note how the static variable x is initialized using a method that writes to the console. This program is guaranteed to write exactly one line to the console: StaticConstructorType will not be initialized unless you give a command line argument to force it into the "else" branch. The way the C# compiler controls this is using the beforefieldinit flag.

So far, so boring. We know exactly when the type will be initialized - I'm going to call this "precise" initialization. This behaviour hasn't changed, and couldn't change without it being backwardly incompatible. Now let's consider what happens without the static constructor.

Eager initialization: .NET 3.5

Let's take the previous program and just remove the (code-less) static constructor - and change the name of the type, for clarity:

using System;

class Eager
{
    private static int x = Log();

    private static int Log()
    {
        Console.WriteLine("Type initialized");
        return 0;
    }

    public static void StaticMethod() {}
}

class EagerTest
{
    static void Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("No args");
        }
        else
        {
            Eager.StaticMethod();
        }
    }
}

Under .NET 3.5, this either writes both "Type initialized" and "No args" (if you don't pass any command line arguments) or just "Type initialized" (if you do). In other words, the type initialization is eager. In my experience, a type is initialized at the start of execution of the first method which refers to that type.

So what about .NET 4.0? Under .NET 4.0, the above code will never print "Type initialized".

If you don't pass in a command line argument, you see "No args" as you might expect... if you do, there's no output at all. The type is being initialized extremely lazily. Let's see how far we can push it...

Lazy initialization: .NET 4.0

The CLR guarantees that the type initializer will be run at some point before the first reference to any static field. If you don't use a static field, the type doesn't have to be initialized... and it looks like .NET 4.0 obeys that in a fairly lazy way. Another test app:

using System;

class Lazy
{
    private static int x = Log();
    private static int y = 0;

    private static int Log()
    {
        Console.WriteLine("Type initialized");
        return 0;
    }

    public static void StaticMethod()
    {
        Console.WriteLine("In static method");
    }

    public static void StaticMethodUsingField()
    {
        Console.WriteLine("In static method using field");
        Console.WriteLine("y = {0}", y);
    }

    public void InstanceMethod()
    {
        Console.WriteLine("In instance method");
    }
}

class LazyTest
{
    static void Main(string[] args)
    {
        Console.WriteLine("Before static method");
        Lazy.StaticMethod();
        Console.WriteLine("Before construction");
        Lazy lazy = new Lazy();
        Console.WriteLine("Before instance method");
        lazy.InstanceMethod();
        Console.WriteLine("Before static method using field");
        Lazy.StaticMethodUsingField();
        Console.WriteLine("End");
    }
}

This time the output is:

Before static method
In static method
Before construction
Before instance method
In instance method
Before static method using field
Type initialized
In static method using field
y = 0
End

As you can see, the type initialized when StaticMethodUsingField is called. It's not as lazy as it could be - the first line of the method could execute before the type is initialized. Still, being able to construct an instance and call a method on it without triggering the type initializer is slightly surprising.

I've got one final twist... what would you expect this program to do?

using System;

class CachingSideEffect
{
    private static int x = Log();

    private static int Log()
    {
        Console.WriteLine("Type initialized");
        return 0;
    }

    public CachingSideEffect()
    {
        Action action = () => Console.WriteLine("Action");
    }
}

class CachingSideEffectTest
{
    static void Main(string[] args)
    {
        new CachingSideEffect();
    }
}

In .NET 4.0, using the Microsoft C# 4 compiler, this does print "Type initialized"... because the C# compiler has created a static field in which to cache the action. The lambda expression doesn't capture any variables, so the same delegate instance can be reused every time. That involves caching it in a static field, triggering type initialization. If you change the action to use Console.WriteLine(this) then it can't cache the delegate, and the constructor no longer triggers initialization.

This bit is completely implementation-specific in terms of the C# compiler, but I thought it might tickle your fancy anyway.

Conclusion

I'd like to stress that none of this should cause your code any problems. The somewhat eager initialization of types without static constructors was entirely legitimate according to the C# and CLR specs, and so the new lazy behaviour of .NET 4.0. If your code assumed that just calling a static method, or creating an instance, would trigger initialization, then that's your own fault to some extent. That doesn't stop it being an interesting change to spot though :)

Contract classes and nested types within interfaces

skeet — Sat, 31 Oct 2009 22:04:54 GMT

I've just been going through some feedback for the draft copy of the second edition of C# in Depth. In the contracts section, I have an example like this:

[ContractClass(typeof(ICaseConverterContracts))]
public interface ICaseConverter
{
    string Convert(string text);
}

[ContractClassFor(typeof(ICaseConverter))]
internal class ICaseConverterContracts : ICaseConverter
{
    string ICaseConverter.Convert(string text)
    {
        Contract.Requires(text != null);
        Contract.Ensures(Contract.Result<string>() != null);
        return default(string);
    }

    private ICaseConverterContracts() {}
}

public class InvariantUpperCaseFormatter : ICaseConverter
{
    public string Convert(string text)
    {
        return text.ToUpperInvariant();
    }
}

The point is to demonstrate how contracts can be specified for interfaces, and then applied automatically to implementations. In this case, ICaseConverter is the interface, ICaseConverterContracts is the contract class which specifies the contract for the interface, and InvariantUpperCaseFormatter is the real implementation. The binary rewriter effectively copies the contract into each implementation, so you don't need to duplicate the contract in the source code.

The reader feedback asked where the contract class code should live - should it go in the same file as the interface itself, or in a separate file as normal? Now normally, I'm firmly of the "one top-level type per file" persuasion, but in this case I think it makes sense to keep the contract class with the interface. It has no meaning without reference to the interface, after all - it's not a real implementation to be used in the normal way. It's essentially metadata. This does, however, leave me feeling a little bit dirty. What I'd really like to be able to do is nest the contract class inside the interface, just like I do with other classes which are tightly coupled to an "owner" type. Then the code would look like this:

[ContractClass(typeof(ICaseConverterContracts))]
public interface ICaseConverter
{
    string Convert(string text);

    [ContractClassFor(typeof(ICaseConverter))]
    internal class ICaseConverterContracts : ICaseConverter
    {
        string ICaseConverter.Convert(string text)
        {
            Contract.Requires(text != null);
            Contract.Ensures(Contract.Result<string>() != null);
            return default(string);
        }

        private ICaseConverterContracts() {}
    }
}

public class InvariantUpperCaseFormatter : ICaseConverter
{
    public string Convert(string text)
    {
        return text.ToUpperInvariant();
    }
}

That would make me feel happier - all the information to do with the interface would be specified within the interface type's code. It's possible that with that as a convention, the Code Contracts tooling could cope without the attributes - if interface IFoo contains a nested class IFooContracts which implements IFoo, assume it's a contract class and handle it appropriately. That would be sweet.

You know the really galling thing? I'm pretty sure VB does allow nested types in interfaces...

Recent activities

skeet — Thu, 03 Sep 2009 23:08:00 GMT

It's been a little while since I've blogged, and quite a lot has been going on. In fact, there are a few things I'd have blogged about already if it weren't for "things" getting in the way.

Rather than writing a whole series of very short blog posts, I thought I'd wrap them all up here...

C# in Depth: next MEAP drop available soon - Code Contracts

Thanks to everyone who gave feedback on my writing dilemma. For the moment, the plan is to have a whole chapter about Code Contracts, but not include a chapter about Parallel Extensions. My argument for making this decision is that Code Contracts really change the feel of the code, making it almost like a language feature - and its applicability is almost ubiquitous, unlike PFX.

I may write a PFX chapter as a separate download, but I'm sensitive to those who (like me) appreciate slim books. I don't want to "bulk out" the book with extra topics.

The Code Contracts chapter is in the final stages before becoming available to MEAP subscribers. (It's been "nearly ready" for a couple of weeks, but I've been on holiday, amongst other things.) After that, I'm going back to the existing chapters and revising them.

Talking in Dublin - C# 4 and Parallel Extensions

Last week I gave two talks in Dublin at Epicenter. One was on C# 4, and the other on Code Contracts and Parallel Extensions. Both are now available in a slightly odd form on the Talks page of the C# in Depth web site. I no longer write "formal" PowerPoint slides, so the downloads are for simple bullet points of text, along with silly hand-drawn slides. No code yet - I want to tidy it up a bit before including it.

Podcasting with The Connected Show

I recently recorded a podcast episode with The Connected Show. I'm "on" for the second 2/3 of the show - about an hour of me blathering on about the new features of C# 4. If you can understand generic variance just by listening to me talking about it, you're a smart cookie ;)

(Oh, and if you like it, please express your amusement on Digg / DZone / Shout / Kicks.)

Finishing up with Functional Programming for the Real World

Well, this hasn't been taking much of my time recently (I bowed out of all the indexing etc!) but Functional Programming for the Real World is nearly ready to go. Hard copy should be available in the next couple of months... it'll be really nice to see how it fares. Much kudos to Tomas for all his hard work - I've really just been helping out a little.

Starting on Groovy in Action, 2nd edition

No sooner does one book finish than another one starts. The second edition of Groovy in Action is in the works, which should prove interesting. To be honest, I haven't played with Groovy much since the first edition of the book was finished, so it'll be interesting to see what's happened to the language in the meantime. I'll be applying the same sort of spit and polish that I did in the first edition, and asking appropriately ignorant questions of the other authors.

Tech Reviewing C# 4.0 in a Nutshell

I liked C# 3.0 in a Nutshell, and I feel honoured that Joe asked me to be a tech reviewer for the next edition, which promises to be even better. There's not a lot more I can say about it at the moment, other than it'll be out in 2010 - and I still feel that C# in Depth is a good companion book.

MoreLINQ now at 1.0 beta

A while ago I started the MoreLINQ project, and it gained some developers with more time than I've got available :) Basically the idea is to add some more useful LINQ extension methods to LINQ to Object. Thanks to Atif Aziz, the first beta version has been released. This doesn't mean we're "done" though - just that we think we've got something useful. Any suggestions for other operators would be welcome.

Manning Pop Quiz and discounts

While I'm plugging books etc, it's worth mentioning the Manning Pop Quiz - multiple choice questions on a wide variety of topics. Fabulous prizes available, as well as one-day discounts:

Monday, Sept 7th: 50% of all print books (code: pop0907)
Monday, Sept 14: 50% off all ebooks (code: pop0914)
Thursday, Sept 17: $25 for C# in Depth, 2nd Edition MEAP print version (code: pop0917) + C# Pop Quiz question
Monday, Sept 21: 50% off all books (code: pop0921)
Thursday, Sept 24: $12 for C# in Depth, 2nd Edition MEAP ebook (code: pop0924) + another C# Pop Quiz question

Future speaking engagements

On September 16th I'm going to be speaking to Edge UG (formerly Vista Squad) in London about Code Contracts and Parallel Extensions. I'm already very much looking forward to the Stack Overflow DevDays London conference on October 28th, at which I'll be talking about how humanity has screwed up computing.

Future potential blog posts

Some day I may get round to writing about:

Revisiting StaticRandom with ThreadLocal<T>
Volatile doesn't mean what I thought it did

There's a lot more writing than coding in that list... I'd like to spend some more time on MiniBench at some point, but you know what deadlines are like.

Anyway, that's what I've been up to and what I'll be doing for a little while...

Tricky decisions... Code Contracts and Parallel Extensions in C# in Depth 2nd edition

skeet — Wed, 05 Aug 2009 16:16:15 GMT

I'd like some feedback from readers, and I suspect my blog is the simplest way to get it.

I'm currently writing chapter 15 of C# in Depth, tentatively about Code Contracts and Parallel Extensions. The problem is that I'm 15 pages in, and I haven't finished Code Contracts yet. I suspect that with a typesetter moving the listings around a little it can be shortened a little bit, but I'm still concerned. With the amount I've still got to write, Code Contracts is going to end up at 20 pages and I expect Parallel Extensions may be 25. That makes for a pretty monstrous chapter for non-language features.

I'd like to present a few options:

Keep going as I am, and take the hit of having a big chapter. I'm not going into huge amounts of detail anyway, but the bigger point is to demonstrate how code isn't what it used to be. We're no longer writing a simple series of statements to be executed in order. Code Contracts changes this dramatically with the binary rewriter, and Parallel Extensions adjusts the parallelism, and ironically makes it easier to write asynchronous code as if it were executed sequentially.
Try to whittle the material down to my original target of around 35 pages. This means it'll be a really cursory glance at each of the technologies - I'm unsure of how useful it would be at all at that point.
Don't even claim to give enough information to really get people going with the new technologies, but possibly introduce extra ones as well, such as PostSharp. Build the theme of "you're not writing C# 1 any more" in a stronger sense - zoom back to show the bigger picture while ignoring the details.
Separate them into different chapters. At this point half the new chapters would be non-language features, which isn't great for the focus of the book... but at least they'd be a more reasonable size.
Ditch the chapters from the book completely, possibly writing them as separate chapters to be available as a mini-ebook companion to the book. (We could possibly include them in the ebook version.) This would make the second edition more focused again and possibly give me a bit more space when revising earlier chapters. However, it does mean there'd only be two full-size new chapters for the second edition. (There'll be a new "wrapping up" chapter as well for a sense of closure, but I'm not generally counting that.)

Other suggestions are welcome, of course. I'm not going to claim that we'll end up doing whatever is suggested here, but I'm sure that popular opinion will influence the final decision.

Thoughts?

Evil Code of the Day: variance and overloading

skeet — Mon, 13 Jul 2009 16:10:00 GMT

(Note that this kind of breakage was mentioned a long time ago in Eric Lippert's blog, although not in this exact form.)

Whenever a conversion becomes available where it wasn't before, overload resolution can change its behaviour. From C# 1 to C# 2 this happened due to delegate variance with method group conversions - now the same thing is true for generic variance for interfaces.

What does the following code print?

using System;
using System.Collections.Generic;

class Base
{
    public void Foo(IEnumerable<string> strings)
    {
        Console.WriteLine("Strings");
    }
}

class Derived : Base
{
    public void Foo(IEnumerable<object> objects)
    {
        Console.WriteLine("Objects");
    }
}

class Test
{
    static void Main()
    {
        List<string> strings = new List<string>();
        new Derived().Foo(strings);
    }
}

The correct answer is "it depends on which version of C# and .NET framework you're using."

If you're using C# 4.0 and .NET 4.0, then IEnumerable<T> is covariant: there's an implicit conversion from IEnumerable<string> to IEnumerable<object>, so the derived overload is used.

If you're using C# 4.0 but .NET 3.5 or earlier then the compiler still knows about variance in general, but the interface in the framework doesn't have the appropriate metadata to indicate it, so there's no conversion available, and the base class overload is used.

If you're using C# 3.0 or earlier then the compiler doesn't know about generic variance at all, so again the base class overload is used.

So, this is a breaking change, and a fairly subtle one at that - and unlike the method group conversion in .NET 2.0, the compiler in .NET 4.0 beta 1 doesn't issue a warning about it. I'll edit this post when there's an appropriate Connect ticket about it...

In general though, I'd say it's worth avoiding overloading a method declared in a base class unless you really have to. In particular, overloading it using the same number of parameters but more general ones seems to be a recipe for unreadable code.

Faking COM to fool the C# compiler

skeet — Tue, 07 Jul 2009 22:28:46 GMT

C# 4 has some great features to make programming against COM components ~~bearable~~ fun and exciting. In particular:

PIA linking allows you to embed just the relevant bits of the Primary Interop Assembly into your own assembly, so the PIA isn't actually required at execution time
Named arguments and optional parameters make life much simpler for APIs like Office which are full of methods with gazillions of parameters
"ref" removal allows you to pass an argument by value even though the parameter is a by-reference parameter (COM only, folks - don't worry!)
Dynamic typing allows you to remove a load of casts by converting every parameter and return type of "object" into "dynamic" (if you're using PIA linking)

I'm currently writing about these features for the book (don't forget to buy it cheap on Friday) but I'm not really a COM person. I want to be able to see these compiler features at work against a really simple type. Unfortunately, these really are COM-specific features... so we're going to have to persuade COM that the type really is a COM type.

I got slightly stuck on this first, but thanks to the power of Stack Overflow, I now have a reasonably complete demo "fake" COM type. It doesn't do a lot, and in particular it doesn't have any events, but it's enough to show the compiler features:

using System;
using System.Runtime.InteropServices;

// Required for linking into another assembly (C# 4)
[assembly:Guid("86ca55e4-9d4b-462b-8ec8-b62e993aeb64")]
[assembly:ImportedFromTypeLib("fake.tlb")]

namespace FakeCom
{
    [Guid("c3cb8098-0b8f-4a9a-9772-788d340d6ae0")]
    [ComImport, CoClass(typeof(FakeImpl))]
    public interface FakeComponent
    {
        object MakeMeDynamic(object arg);

        void Foo([Optional] ref int x,
                 [Optional] ref string y);
    }

    [Guid("734e6105-a20f-4748-a7de-2c83d7e91b04")]
    public class FakeImpl {}
}

We have an interface representing our COM type, and a class which the interface claims will implement it. Fortunately the compiler doesn't actually check that, so we can get away with leaving it entirely unimplemented. It's also worth noting that our optional parameters can be by-reference parameters (which you can't normally do in C# 4) and we haven't given them any default values (as those are ignored for COM anyway).

This is compiled just like any other assembly:

csc /target:library FakeCom.cs

Then we get to use it with a test program:

using FakeCom;

class Test
{
    static void Main()
    {
        // Yes, that is calling a "constructor" on an interface
        FakeComponent com = new FakeComponent();

        // The boring old fashioned way of calling a method
        int i = 0;
        string j = null;
        com.Foo(ref i, ref j);

        // Look ma, no ref!
        com.Foo(10, "Wow!");

        // Who cares about parameter ordering?
        com.Foo(y: "Not me", x: 0);

        // And the parameters are optional too
        com.Foo();

        // The line below only works when linked rather than
        // referenced, as otherwise you need a cast.
        // The compiler treats it as if it both takes and
        // returns a dynamic value.
        string value = com.MakeMeDynamic(10);
    }
}

This is compiled either in the old "deploy the PIA as well" way (after adding a cast in the last line):

csc /r:FakeCom.dll Test.cs

... or by linking the PIA instead:

csc /l:FakeCom.dll Test.cs

(The difference is just using /l instead of /r.)

When the test code is compiled as a reference, it decompiles in Reflector to this (I've added whitespace for clarity):

private static void Main()
{
    FakeComponent component = (FakeComponent) new FakeImpl();

    int x = 0;
    string y = null;
    component.Foo(ref x, ref y);

    int num2 = 10;
    string str3 = "Wow!";
    component.Foo(ref num2, ref str3);

    string str4 = "Not me";
    int num3 = 0;
    component.Foo(ref num3, ref str4);

    int num4 = 0;
    string str5 = null;
    component.Foo(ref num4, ref str5);

    string str2 = (string) component.MakeMeDynamic(10);
}

Note how the compiler has created local variables to pass by reference; any changes to the parameter are ignored when the method returns. (If you actually pass a variable by reference, the compiler won't take that away, however.)

When the code is linked instead, the middle section is the same, but the construction and the line calling MakeMeDynamic are very different:

private static void Main()
{
    FakeComponent component = (FakeComponent) Activator.CreateInstance(Type.GetTypeFromCLSID
        (new Guid("734E6105-A20F-4748-A7DE-2C83D7E91B04")));

    // Middle bit as before

    if (<Main>o__SiteContainer6.<>p__Site7 == null)
    {
        <Main>o__SiteContainer6.<>p__Site7 = CallSite<Func<CallSite, object, string>>
            .Create(new CSharpConvertBinder
                       (typeof(string),
                        CSharpConversionKind.ImplicitConversion, false));
    }
    string str2 = <Main>o__SiteContainer6.<>p__Site7.Target.Invoke
        (<Main>o__SiteContainer6.<>p__Site7, component.MakeMeDynamic(10));
}

The interface is embedded in the generated assembly, but with a slightly different set of attributes:

[ComImport, CompilerGenerated]
[Guid("C3CB8098-0B8F-4A9A-9772-788D340D6AE0"), TypeIdentifier]
public interface FakeComponent
{
object MakeMeDynamic(object arg);
void Foo([Optional] ref int x, [Optional] ref string y);
}

The class isn't present at all.

I should point out that doing this has no practical benefit in real code - but the ability to mess around with a pseudo-COM type rather than having to find a real one with the exact members I want will make it a lot easier to try a few corner cases for the book.

So, not a terribly productive evening in terms of getting actual writing done, but interesting nonetheless...

Evil code of the day

skeet — Fri, 03 Jul 2009 22:28:26 GMT

At a glance, this code doesn't look particularly evil. What does it do though? Compile it with the C# 4.0b1 compiler and run it...

using System;

class Base
{
    public virtual void Foo(int x, int y)
    {
        Console.WriteLine("Base: x={0}, y={1}", x, y);
    }
}

class Derived : Base
{
    public override void Foo(int y, int x)
    {
        Console.WriteLine("Derived: x={0}, y={1}", x, y);
    }
}

class PureEvil
{
    static void Main()
    {
        Derived d = new Derived();
        Base b = d;

        b.Foo(x: 10, y: 20);
        d.Foo(x: 10, y: 20);
    }
}

The results are:

Derived: x=20, y=10
Derived: x=10, y=20

I'm very nearly tempted to leave it there and just see what the reactions are like, but I'll at least give you a hint as to where to look - section 21.3 of the C# 4 spec explains why this gives odd results. It does make perfect sense, but it's hideously evil.

I feel dirty.

Bonus questions

What happens if you rename the parameters in Derived.Foo to yy and xx?
(As suggested by Mehrdad) What happens if you call it with a dynamic value?

OS Jam at Google London: C# 4 and the DLR

skeet — Fri, 19 Jun 2009 16:50:00 GMT

Last night I presented for the first time at the Google Open Source Jam at our offices in London. The room was packed, but only a very few attendees were C# developers. I know that C# isn't the most popular language on the Open Source scene, but I was still surprised there weren't more people using C# for their jobs and hacking on Ruby/Python/etc at night.

All the talks at OSJam are just 5 minutes long, with 2 minutes for questions. I'm really not used to this format, and felt extremely rushed... however, it was still a lot of fun. I used a somewhat different approach to my slides than the normal "bullet points in PowerPoint" - and as it was only short, I thought I might as well effectively repeat the presentation here in digital form. (Apologies if the images are an inconvenient size for you. I tried a few different ones, and this seemed about right. Comments welcome, as I may do a similar thing in the future.)

	Introductory slide. Colleagues forced me to include the askjonskeet.com link.
	.NET isn't Open Source. You can debug through a lot of the source code for the framework if you agree to a "reference licence", but it's not quite the same thing.
	.NET isn't Open Source, but the DLR is. And IronRuby. And IronPython. Yay! And of course Mono is Open Source: the DLR and Mono play nicely together, and the Mono team is hoping to implement the new C# 4.0 features for the 2.8 release in roughly the same timeframe as Microsoft.
	This is what .NET 4.0 will look like. The DLR will be included in it, despite being open source. IronRuby and IronPython aren't included, but depend heavily on the DLR. (Currently available versions allow you to use a "standalone" DLR or the one in .NET 4.0b1.) C# doesn't really depend on the DLR except for its handling of `dynamic`. C# is a statically typed language, but C# 4.0 has a new static type called `dynamic` which you can do just about anything with. (This got a laugh, despite being a simple and mostly accurate summary of the dynamic typing support in C# 4.0.)
	The fundamental point of the DLR is to handle call sites - decide what to do dynamically with little bits of code. Oh, and do it quickly. That's what the caches are for. They're really clever - particularly the L0 cache which compiles rules (about the context in which a particular decision is valid) into IL via dynamic methods. Awesome stuff. I'm sure the DLR does many other snazzy things, but this feels like it's the core part of it.
	At execution time, the relevant binder is used to work out what a call site should actually do. Unless, that is, the call has a target which implements the shadowy `IDynamicMetaObjectProvider` interface (winner of "biggest mouthful of a type name" prize, 2009) - in which case, the object is asked to handle the call. Who knows what it will do?
	Beautifully syntax-highlighted C# 4.0 source code showing the `dynamic` type in action. The method calls on lines 2 and 3 are both dynamic, even though in the latter case it's just using a static method. Which overload will it pick? It all depends on the type of the actual value at execution time. If I'd had more time, I'd have demonstrated how the C# compiler preserves the static type information it knows at compile time for the execution time binder to use. This is very cool, but would take far too long to demonstrate in this talk - especially to a bunch of non-C# developers.
	There were a couple of questions, but I can't remember them offhand. Someone asked me afterwards about how all this worked on non-.NET implementations (i.e. Mono, basically). I gather the DLR itself works, but I don't know whether C# code compiled in the MS compiler will work at the moment - it embeds references to binder types in Microsoft.CSharp.dll, and I don't know what the story is about that being supported on Mono.

This is definitely the format I want to use for future presentations. It's fun to write, fun to present, and I'm sure the "non-professionalism" of it makes it a lot more interesting to watch. Although it's slower to create text-like slides (such as the first and the last one) this way, the fact that I don't need to find clip-art or draw boxes with painful user interfaces is a definite win - especially as I'm going to try to be much more image-biased from now on. (I don't want people reading slides while I'm talking - they should be listening, otherwise it's just pointless.)

Dynamic type inference and surprising possibilities

skeet — Wed, 17 Jun 2009 20:01:13 GMT

There have been mutterings about the fact that I haven't been blogging much recently. I've been getting down to serious work on the second edition of C# in Depth, and it's taking a lot of my time. However, I thought I'd share a ghastly little example I've just come up with.

I've been having an email discussion with Sam Ng, Chris Burrows and Eric Lippert about how dynamic typing works. Sam mentioned that even for dynamically bound calls, type inference can fail at compile time. This can only happen for type parameters where none of the dynamic values contribute to the type inference. For example, this fails to compile:

static void Execute<T>(T item, int value) where T : struct {}
...
dynamic guid = Guid.NewGuid();
Execute("test", guid);

Whatever the value of guid is at execution time, this can't possibly manage to infer a valid type argument for T. The only type which can be inferred is string, and that's not a value type. Fair enough... but what about this one?

static void Execute<T>(T first, T second, T third) where T : struct {}
...
dynamic guid = Guid.NewGuid();
Execute(10, 0, guid);
Execute(10, false, guid);
Execute("hello", "hello", guid);

I expected the first call to compile (but fail at execution time) and the second and third calls to fail at compile time. After all, T couldn't be both an int and a bool could it? And then I remembered implicit typing... what if the vaue of guid isn't actually a Guid, but some struct which has an implicit conversion from int, bool and string? In other words, what if the full code actually looked like this:

using System;

public struct Foo
{
    public static implicit operator Foo(int x)
    {
        return new Foo();
    }

    public static implicit operator Foo(bool x)
    {
        return new Foo();
    }

    public static implicit operator Foo(string x)
    {
        return new Foo();
    }
}

class Test
{
    static void Execute<T>(T first, T second, T third) where T : struct {}

    static void Main()
    {
        dynamic foo = new Foo();
        Execute(10, 0, foo);
        Execute(10, false, foo);
        Execute("hello", "hello", foo);
    }
}

Then T=Foo is a perfectly valid inference. So yes, it all compiles - and the C# binders even get it all right at execution time. So much for any intuition I might have about dynamic typing and inference...

No doubt I'll have similar posts about new C# 4 features occasionally... but they're more likely to be explanations of misunderstandings than deep insights into a correct view of the language. Those end up in the book instead :)

C# 4.0: dynamic ?

skeet — Thu, 30 Oct 2008 22:04:10 GMT

I've not played with the VS2010 CTP much yet, and I've only looked briefly at the documentation and blogs about the new C# 4.0 dynamic type, but a thought occurred to me: why not have the option of making it generic as a way of saying "I will dynamically support this set of operations"?

As an example of what I mean, suppose you have an interface IMessageRouter like this:

public interface IMessageRouter
{
void Send(string message, string destination);
}

(This is an arbitrary example, by the way. The idea isn't specifically more suitable for message routing than anything else.)

I may have various implementations, written in various languages (or COM) which support the Send method with those parameters. Some of those implementations actually implement IMessageRouter but some don't. I'd like to be able to do the following:

dynamic<IMessageRouter> router = GetRouter();

// This is fine (but still invoked dynamically)
router.Send("message", "skeet@pobox.com");
// Compilation error: no such overload
router.Send("message", "skeet@pobox.com", 20);

Intellisense would work, and we'd still have some of the benefits of static typing but without the implementations having to know about your interface. Of course, it would be quite easy to create an implementation of the interface which did exactly this - but now imagine that instead of IMessageRouter we had MessageRouter - a concrete class. In this case the compiler would still restrict the caller to the public API of the class, but it wouldn't have to be the real class. No checking would be performed by the compiler that your dynamic type actually supported the operations - given that we're talking about dynamic invocation, that would be impossible to do. It would instead be an "opt-in" restriction the client places on themselves. It could also potentially help with performance - if the binding involved realised that the actual type of the dynamic object natively implemented the interface or was/derived from the class, then no real dynamic calls need be made; just route all directly.

This may all sound a bit fuzzy - I'm extremely sleepy, to be honest - but I think it's a potentially interesting idea. Thoughts?

Update

Apparently this post wasn't as clear as it might be. I'm quite happy to keep the currently proposed dynamic type idea as well - I'd like this as an additional way of using dynamic objects.

DotNetRocks interview

skeet — Tue, 07 Oct 2008 16:33:49 GMT

Last Monday evening I had a chat with the guys from DotNetRocks, and today the show has gone live.

I wouldn't claim to have said anything particularly earth-shattering, and regular readers will probably be familiar with many of the themes anyway, but I thoroughly enjoyed it and hope you will too. Amongst other things, we talked about:

Protocol buffers
Implicit typing and anonymous types
Why it doesn't bother me that Office hasn't been ported to .NET
C# 4
My wishlist for C#
Threading and Parallel Extensions
Working for Google
How to learn LINQ
C# in Depth

Feedback welcome. And yes, I know I sound somewhat like a stereotypical upper-class idiot at times. Unfortunately there's not a lot I can do about that. Only the "idiot" part is accurate :)

C# 4: Immutable type initialization

skeet — Sat, 15 Mar 2008 23:02:29 GMT

(I'm giving up with the numbering now, unless anyone particularly wants me to keep it up. What was originally going to be a limited series appears to be growing without end...)

As Chris Nahr pointed out in my previous post, my earlier idea about staged initialization was very half-baked. As he's prompted me to think further about it, I've come up with another idea. It's slightly more baked, although there are lots of different possibilities and open questions.

Let's take a step back, and look at my motivation: I like immutable types. They're handy when it comes to thread safety, and they make it a lot easier to reason about the world when you know that nothing can change a certain value after it's been created. Now, the issues are:

We really want to be able to fully construct the object in the constructor. That means we can mark all fields as initonly in the generated IL, potentially giving the CLR more scope for optimisation.
When setting more than two or three values (while allowing some to be optional) constructor overloading ends up being a pain.
Object initializers in C# 3 only apply to properties and fields, not method/constructor arguments - so we can't get the clarity of naming.
Ideally we want to support validation (or possibly other code) and automatic properties.
The CLR won't allow initonly fields being set anywhere other than in the constructor - so even if we made sure we didn't call any setters other than in the constructor, we still couldn't use them to set the fields.
We want to allow simple construction of immutable types from code other than C#. In particular, I care about being able to use projects like Spring.NET and Castle/Windsor (potentially after changes to those projects) to easily create instances of immutable types without resorting to looking up the order of constructor parameters.

The core of the proposal is to be able to mark properties as initonly, and get the compiler to create an extra type which is thoroughly mutable, and contains those properties - as well as a constructor which accepts an instance of the extra type and uses it to populate the immutable instance of the main type before returning.

Extra syntax could then be used to call this constructor - or indeed, given that the properties are actually readonly, thus avoiding any ambiguity, normal object initializers could be used to create instances.

Just as an example, imagine this code:

public class Address
{
    public string Line1 { get; initonly set; }
    public string Line2 { get; initonly set; }
    public string Line3 { get; initonly set; }
    public string County { get; initonly set; }
    public string State { get; initonly set; }
    public string Country { get; initonly set; }
    public string ZipCode { get; initonly set; }

    // Business methods as normal
}

// In another class
Address addr = new Address
{
    Line1="10 Fairview Avenue",
    Line3="Makebelieve Town",
    County="Mono County",
    State="California",
    Country="US"
};

That could be transformed into code a bit like this:

// Immutable class

// Let tools (e.g. the compiler!) know how we
// expect to be initialized. Could be specified
// manually to avoid using the default class name
[InitializedWith(typeof(Address.Init))]
public class Address
{
    // Nested mutable class used for initialization
    [CompilerGenerated]
    public class Init
    {
        public string Line1 { get; set; }
        public string Line2 { get; set; }
        public string Line3 { get; set; }
        public string County { get; set; }
        public string State { get; set; }
        public string Country { get; set; }
        public string ZipCode { get; initonly set; }
    }

    // Read-only "real" properties, automatically
    // implemented and backed with initonly fields
    public string Line1 { get; }
    public string Line2 { get; }
    public string Line3 { get; }
    public string County { get; }
    public string State { get; }
    public string Country { get; }
    public string ZipCode { get; }

    // Automatically generated constructor, using
    // backing fields directly
    public Address(Address.Init init)
    {
        <>_line1 = init.Line1;
        <>_line2 = init.Line2;
        <>_line3 = init.Line3;
        <>_county = init.County;
        <>_state = init.State;
        <>_country = init.Country;
        <>_zipCode = init.ZipCode;
    }

    // Business methods as normal
}

// In another class
Address addr = new Address(new Address.Init
{
    Line1="10 Fairview Avenue",
    Line3="Makebelieve Town",
    County="Mono County",
    State="California",
    Country="US"
});

That's the simple case, of course. Issues:

Unlike other compiler-generated types (anonymous types, types for iterator blocks, types for anonymous functions) we do want this to be public, and have a name which can be used elsewhere. We need to find some way of making sure it doesn't clash with other names. In the example above, I've used an attribute to indicate which type is used for initialization - I could imagine some way of doing this in the "pre-transform" code to say what the auto-generated type should be called.
What happens if you put code in the setter, instead of making it automatically implemented? I suspect that code should be moved into the setter of the initialization class - but at that point it won't have access to the rest of the state of the class (beyond the other properties in the initialization class). It's somewhat messy.
What if you want to add code to the generated constructor? (Possibly solution: allow constructors to be marked somehow in a way that means "add on the initialization class as a parameter at the end, and copy all the values as a first step.)
How can you indicate that some parameters are mandatory, and some are optional? (The mandatory parameters could just be marked as readonly properties rather than initonly, and then the initialization class specified as an extra parameter for a constructor which takes all the mandatory ones. Doesn't feel elegant though, and leaves you with two different types of initialization code being mixed in the client - some named, some positional.)
How do you specify default values? (They probably end up being the default values of the automatically generated properties of the initialization class, but there needs to be some syntax to specify them.)

I suspect there are more issues too - but I think the benefits would be great. I know the C# team has been thinking about immutability, but I've no idea what kind of support they're currently envisioning. Unlike my previous ideas, which were indeed unpalatable for various reasons, I think this one has real potential. Mind you, given that I've come up with it after only mulling this over in "spare" time, I highly doubt that it will be a new concept to the team...

C# 4 idea: Iterator blocks and parameter checking

skeet — Sun, 02 Mar 2008 19:54:44 GMT

Iterator blocks have an interesting property: they defer execution. When the method (or property) is called, none of your code is executed - it only starts running when MoveNext() is first called.

Deferred execution is a great thing in many ways, but it's a pain when it comes to parameter checking. If you check parameters within an iterator block, you've effectively left a timebomb - the error will be potentially reported a long way from the original source of the problem. (Side-note: this is why I prefer using a cast to as when I know what type something really should be - I'd rather get an InvalidCastException immediately than a NullReferenceException later on.)

One solution to this is to check the parameters in the public method and then call a private method which is implemented with an iterator block. That's a bit ugly though. It would be nice to be able to specify the parameter checking in an initial block which could only occur at the start of the method - something like this simple implementation of Repeat:

public static IEnumerable<TResult> Repeat<TResult>(TResult element, int count)
{
    yield do
    {
        if (count < 0)
        {
            throw new ArgumentException(count);
        }
    }
    for (int i=0; i < count; i++)
    {
        yield return element;
    }
}

I've chosen yield do for two reasons: it fits in with the rest of the yield pattern, and by using an existing keyword I suspect it reduces/eliminates the chance of this being a breaking change. It's not ideal from the point of self-description, but do is the closest keyword I could find when I looked at the spec. In a language with begin as a keyword, that would probably be a better choice - or initial. fixed appeals in that the code is fixed in the method rather than being shunted off into the compiler-generated type, but the normal use of fixed is far too different to make this an appealing choice. Any other suggestions are very welcome :)

Is this an important enough change to make it worth including in C# 4? I'm not sure. The negative side is that I suspect relatively few people use iterator blocks much, so it may not have a very wide benefit. The positive side is that it only actually makes any difference to those who do use iterator blocks, and I believe almost all of them would find it a welcome addition. It's simple to understand, and it makes iterator blocks much easier to use in a "correct" manner when any form of initial checking is involved.

Note, mostly to myself and Marc Gravell: I haven't checked, but I suspect most of Push LINQ is broken in this respect.

Further note to self - I really need to fix my code formatter to treat yield as a contextual keyword.

Language design, when is a language "done", and why does it matter?

skeet — Mon, 11 Feb 2008 23:45:31 GMT

As per previous posts, I've been thinking a fair amount about how much it's reasonable to keep progressing a language. Not only have thoughts about C# 4 provoked this, but also a few other sources:

Don Box on Ted Neward on Java (yes, two separate links - but view both)
Don again on the "doneness" of XML
The Channel9 video of Erik Meijer, Gilad Bracha and Mads Torgersen

The video is very well worth watching in its entirety - even though I wouldn't pretend to understand everything in it. (It's worth watching rather than just listening to, by the way - Gilad's body language is very telling.) Here are just a few of the things which particularly caught my attention:

Mads, 14:45 on the "Babelification" which could occur if everyone plugs in their own type system into a pluggable language. This is similar to my concern about LISP-like macros in C#, I think.
Gilad, 23:40: "We're the kind of people who love to learn new things. Most people hate to learn new things." I don't agree with that - but I'd say that people hate to feel they're on a treadmill where they spent all their time learning, with no chance to actually use what they've learned.
Gilad, 28:35: "People never know when to stop [...] What happens is they do too much."
Mads, 50:50: "The perfect language is the one that helps you do your task well, and that varies from task to task."

So, what does this have to do with C#? Well, I was wondering how different people would respond when asked if C# was "done". Eric's certainly remarked that it's nowhere near done - whereas prior to C# 3, I think I'd have called C# 2 "done". C# 3 has opened my eyes a little about what might be possible - how radical changes can be made while still keeping a coherent language.

I've been worrying publicly about the burden of learning which is being placed on developers. I'm starting to change my thoughts now (yes, even since yesterday). I've started to wonder where the burden is coming from, and why it matters if C# changes even more radically in the future.

Who would make you learn or use C# 4?

Suppose the C# team went nuts, and decided that C# 4 would include:

x86 inline assembly
Optional reverse Polish notation, which could be mixed and matched with the existing syntax
Checked exceptions
Regular expressions as a language feature, but using a new and slightly different regex dialect
User-defined operators (so you could define the "treble clef" operator, should you wish to)
Making semi-colons optional, but whitespace significant. (Heck, we could remove braces at the same time - optionally.)
A scripting mode, where Console.WriteLine("Hello") would count as a complete program

I'm assuming that most readers wouldn't want to use or even learn such a language. Would you do it anyway though? Bear it in mind.

Now suppose the C# team worked out ways of including significant pieces of obscure but powerful computer science into C# 4 instead. Lots to learn, but with great rewards. It's backwardly compatible, but idiomatic C# 4 looks totally different to C# 3.

Here's the odd thing: I'd be more comfortable with the first scenario than the second. Why? Because the first lets me get on with developing software, guilt-free. There'd be no pressure to learn a lunatic version of C# 4, whereas if it's reasonably compelling I'll have to find the time. It's unlikely (in most companies anyway) that I'll be given the time by my employers - there might be a training course if I'm lucky, but we all know that's not really how you learn to use a language productively. You learn it by playing and experimenting in conjunction with the more theoretical training or reading. I like to learn new things, but I'm already several technologies behind.

What's in a name?

Now consider exactly the same scenario, but where instead of "C# 4" the language is named "Gronk#". In both cases it's still backwardly compatible with C# 3.

Logically, the name of the language should make no difference whatsoever. But it does. As a C# developer, I feel an obligation (both personal and from my employer) to keep up with C#. If you're a C# developer who isn't at least looking at C# 3 at the moment, you're likely to find yourself behind the field. Compare that with F#. I'm interested to learn F# properly, and I really will get round to it some time - but I feel no commercial pressure to do so. I'm sure that learning a functional language would benefit many developers - as much (or even more) for the gains in perspective when writing C# 3 as for the likelihood of using the functional language directly in a commercial setting. But hey, it's not C# so there's no assumption that it's on my radar. Indeed, I suspect that if I polled my colleagues, many wouldn't have even heard of F#. They're good engineers, but they have a home life which doesn't involve obsessing over computer languages (yeah, I find it hard to believe too), and at work we're busy building products.

We could potentially have more "freedom" if every language release came with a completely different name. It would happen to be able to build the old code, but that could seem almost incidental. (It would also potentially give more room for breaking changes, but that's a very different matter.) There'd be another potential outcome - branching.

Consider the changes I've proposed for C# 4. They are mere tweaks. They keep the language headed in the same direction, but with a few minor bumps removed. Let's call this Jon#.

Now consider a language which (say) Erik Meijer might build as the successor to C# 3. I'm sure there are plenty of features from Haskell which C# doesn't have yet. Let's suppose Erik decides to bundle them all into Erik#. (For what it's worth, I don't for one moment believe that Erik would actually treat C# insensitively. I have a great respect for him, even if I don't always understand everything he says.)

Jon# and Erik# can be independent. There's no need for Erik# to contain the changes of Jon# if they don't fit in with the bigger picture. Conservative developers can learn Jon# and make their lives a bit easier for little investment. Radical free thinkers can learn Erik# in the hope that it can give them really big rewards in the long run. Everyone's happy. Innovation and pragmatism both win.

Well, sort of.

We've then got two language specs, two compilers, two IDE experiences, etc. That hurts. Branching gives some freedom at the cost of maintenance - as much here as in source control.

Where do we go from here?

This has been a meandering post, which is partly due to the circumstances in which I've written it, and partly due to the inconclusive nature of my thoughts on the matter. I guess some of the main points are:

Names matter - not just in terms of getting attention, but in the burden of expected learning as well.
Contrary to impressions I may have given before, I really don't want to be a curmudgeonly stifler of language innovation. I just worry about unintended effects which are more to do with day to day human reality than technical achievement.
There are always options and associated costs - branching being one option which gives freedom at a high price

I really don't have a good conclusion here - but I hope plenty of people will spare me their thoughts on this slightly non-technical matter as readily as they have about specific C# 4 features.

C# 4, part 4: My manifesto and wishlist

skeet — Sun, 10 Feb 2008 22:01:00 GMT

The final part of this little series is the one where I suggest my own ideas for C# 4, beyond those I've already indicated my approval for in earlier posts. Before I talk about individual features, however, I'd like to put forward a manifesto which could perhaps help the decision-making process. I hasten to add that I haven't run all the previous parts through this manifesto to make sure that I've been consistent, but all of these thoughts have been running around in my head for a while so I hope I haven't been wildly out.

Manifesto for C# 4

I would welcome the following goals:

Remember it's C#

Many suggestions have been trying to turn C# into either Ruby, LISP, or other languages. I welcome diversity in languages, and I believe in using the right tool for the job - but that means languages should stick to their core principles, too. Now, I know that sounds like I might be bashing C# 3, given how much that has borrowed from elsewhere for lambda expressions and the like, and I don't know exactly how I square that circle internally - but I don't want C# to become a giant toolbox that every useful feature from every language in existence is dumped into.

There are useful ideas to think about from all kinds of areas - not just existing languages - but I'd be tempted to reject them if they just don't fit into C# neatly without redefining the whole thing.

Consider how people will learn it

I've mentioned this before, but I am truly worried about people learning C# 3 from scratch. One of the reasons I didn't attempt to write about C# from first principles, instead assuming knowledge of C# 1, is that I'm not sure people can sensibly learn it that way. Now, I don't think I can sensibly get inside the head of someone who doesn't know anything about C#, but I suspect that I'd want to cover query expressions right at the very end, preferably after quite a while of experience in C# without them.

That might not go for every new feature - it's probably worth knowing about automatic properties right from the start, for instance, and introducing lambda expressions at the same time as anonymous methods (if C# 3 is the definite goal) but expression trees would be pretty late in my list of topics.

I learned C# 1 from a background of Java, and it didn't take long to understand the basics of the syntax. Many of the subtleties took a lot longer of course (and it was a very long time before I really understood the differences between events and delegates, I'm sad to say) but it wasn't a hard move. For a long time C# 2 just meant generics as far as I was concerned - with occasional nullable types, and some of the simpler features such as differing access for getters and setters. Anonymous methods and iterator blocks didn't really hit me in terms of usefulness until much later - possibly due to using closures in Groovy and more iterators in LINQ. I suspect for many C# 2 developers this is still the case.

My method of learning C# 3 (from the spec, often in rather more detail than normal for the sake of accuracy in writing) is sufficiently far off the beaten track as to make it irrelevant for general purposes, but I wonder how people will learn it in reality. How will it be taught in universities (assuming there are any that teach C#)? How easily will developers moving to C# from Java cope? How about from other languages?

Interestingly, the move from VB 9 to C# 3 is now probably easier than the move from Java 6 to C# 3. Even with the differences in generics between Java and C#, that probably wasn't true with C# 2.

To get back to C# 4, I'd like the improvements to be somehow blend in so that learning C# 4 from scratch isn't a significantly different experience to learning C# 3 from scratch. It's bound to be slightly longer as there will certainly be new features to learn - but if they can be learned alongside existing features, I think that's a valuable asset. It's also worth considering how much investment will be required to learn C# 4 from a position of understanding C# 3. Going from C# 2 to C# 3 is a significant task - but it's one which involves a paradigm shift, and of course the payoffs are massive. I'd be very surprised (and disappointed) to see the same level of change in C# 4, or indeed the same level of payoff. Conservative though this is, I'm after "quick wins" for developers - even if in some cases such as covariance/contravariance the win is far from quick from the C# design/implementation team's perspective.

Just to put things into perspective: think about how many new technologies developers have being asked to learn in the last few years - WCF, WPF, Workflow Foundation, Cardspace, Silverlight, AJAX, LINQ, ClickOnce and no doubt other things I've forgotten. I feel a bit like Joseph II complaining that Mozart had written "too many notes" - and if you asked me to start exorcising any of these technologies from history I'd be horrified at the prospect. That doesn't actually make it any easier for us though. I doubt that the pace of change is likely to slow down any time soon in terms of technologies - let's not make developers feel like complete foreigners in a language they were happy with.

Keep the language spec understandable

I know there aren't many people who look at the language spec, but the C# spec has historically been very, very well written. It's usually clear (even if it can be hard to find the right section at times) and leaves rigidly defined areas of doubt and uncertainty in appropriate places, while stamping out ambiguity in others. The new unified spec is a great improvement over the "C# 1 ... and then the new bits in C# 2" approach from before. However, it's growing at a somewhat alarming rate. As it grows, I expect it to become harder to read as a natural consequence - unless particular effort is put into countering that potential problem.

Stay technology-neutral...

Okay, this one is aimed fairly squarely at VB9. I know various people love XML literals, but I'm not a fan. It just feels wrong to have such close ties with a particular technology in the actual language, even one so widely used as XML. (Of course, there's already a link between XML and C# in terms of documentation comments - but that doens't feel quite as problematic.)

My first reaction to LINQ (before I understood it) was that C# was being invaded by SQL. Now that I've got a much better grasp of query expressions, I have no concern in that area. Perhaps it would be possible to introduce a new hierarchy construct which LINQ to XML understands with ease - or adapt the existing object/collection initializers slightly for this purpose. With some work, it may be possible to do this without restricting it to XML... I'm really just blue-skying though (and this isn't a feature on my wishlist.)

... but bear concurrency in mind

While I don't like the idea of tying C# to any particular technology, I think the general theme of concurrency is going to be increasingly important. That's far from insightful - just about every technology commentator in the world is predicting a massively parallel computing landscape in the future. Developers won't be able to get away with blissful ignorance of concurrency, even if not everyone will need to know the nuts and bolts.

Make it easier to do the right thing

This is effectively encouraging developers to "fall into the pit of success". Often best practices are ignored as being inconvenient or impractical at times, and I'm certainly guilty of that myself. C# has a good history of enabling developers to do the right thing more easily as time progresses: automatic properties, iterator blocks and allowing different getter/setter access spring to mind as examples.

In some ways this is the biggest goal in this manifesto. It's certainly guided me in terms of encouraging mixin and immutability support, ways of simplifying parameter/invariant checking, and potentially IDisposable implementation. I like features which don't require me to learn whole new ways of approaching problems, but let me do what I already knew I should do, just more easily.

Wishlist of C# 4 features

With all that out of the way, what would I like to see in C# 4? Hopefully from the above you won't be expecting anything earth-shattering - which is a good job, as all of these are reasonably minor modifications. Perhaps we could call it C# 3.5, shipping with .NET 4.0. That would really make life interesting, as people are already referring to C# 3 as C# 3.5 (and C# 2008)...

Readonly automatic properties

I've mentioned this before, but I'll give more details here. I'd like to be able to specify readonly instead of protected/internal/private for the setter access, which would:

Mark the autogenerated backing variable as initonly in IL
Prevent code outside the constructor from setting the property

So, for example:

class ReadOnlyDemo
{
    public string Name { get; readonly set; }

    public ReadOnlyDemo(string name)
    {
        // Valid
        Name = name;
    }

    public void TryToSetName(string newName)
    {
        // Invalid
        Name = newName;
    }
}

This would make it easier to write genuinely (and verifiably, as per Joe's post) immutable classes, or just immutable parts of classes. As mentioned in previous comments, there could be interesting challenges around serialization and immutability, but frankly they really need to be addressed anyway - immutability is going to be one part of the toolkit for concurrency, whether it has language support or not. In the generated IL the property would only have a getter - calls to the setter in the constructor would be translated into direct variable sets.

This shouldn't require a CLR change.

Property-scoped variables

I've been suggesting this (occasionally) for a long time, but it's worth reiterating. Every so often, you really want to make sure that no code messes around with a variable other than through a property. This can be solved with discipline, of course - but historically we don't have a good record on sticking to discipline. Why not get the compiler to enforce the discipline? I would consider code like this:

public class Person
{
    public int Age
    {
        // Variable is not accessible outside the Age property
        int age;
        get
        {
            return age;
        }
        set
        {
            if (value < 0 || value > SomeMaxAgeConstant)
            {
                throw new ArgumentOutOfRangeException();
            }
            age = value;
        }
    }

    public void SetAgeNicely(int value)
    {
        // Perfectly legal
        Age = value;
    }

    public void SetAgeSneakily(int value)
    {
        // Compilation error!
        age = value;
    }
}

Just in case Eric's reading this: yes, having Age as a property of a person is a generally bad idea. Specifying a date of birth and calculating the age is a better idea. Really, don't use this code as a model for a Person type. However, treat it as a dumb example of a reasonable idea. I need to find myself a better type to use as my first port of call when finding an example...

The variable name would still have to be unique - it would still be the name generated in the IL, for instance. Multiple variables could be declared if required. The generated code could be exactly the same as that of existing code which happened to only use the property to access the variable.

A couple of potential options:

The variables could be directly accessible during the constructor, potentially. This would help with things like serialization.
Likewise, potentially an attribute could be applied to other members which needed access to the variables. Bear in mind that we're only trying to save developers from themselves (and their colleagues). We're not trying to cope with intruders in a security sense. An active "I know I'm violating my own rules" declaration should cause enough discomfort to avoid the accidental issues we're trying to avoid.

This shouldn't require a CLR change.

Extension properties

This has been broadly talked about, particularly in view of fluent interfaces. It feels to me that there are two very different reasons for extension properties:

Making fluent interfaces prettier, e.g. 19.June(1976) + 8.Hours + 20.Minutes instead of 19.June(1976) + 8.Hours() + 20.Minutes()
Genuine properties, which of course couldn't add new state to the extended type, but could access it in a different way.

Point 1 feels like a bit of a hack, I must admit. It's using properties not because the result is "property-like" but because we want to miss the brackets off. It's been pointed out to me that VB already allows this, and that by brackets to be missed out for parameterless methods we could achieve the same effect - but that just feels wrong. Arguably fluent interfaces already mess around with the normal conventions of what methods do and how they're named, so using properties like this probably isn't too bad.

Point 2 is a more natural reason for extension properties. As an example, consider a type which exposes a Size property, but not Width or Height. Changing either dimension individually requires setting the Size to a new one with the same value for the other dimension - this is often much harder to read than judicious use of Height/Width. I suspect that extension properties would actually be used for this reason less often than for fluent interfaces, but there may be any number of interesting uses I haven't thought of.

This shouldn't require a CLR change, but framework changes may be required.

Extension method discovery improvements

I've made it clear before now that the way extension methods are discovered (i.e. with using directives which import all the extension methods of all the types within the specified namespace) leaves much to be desired. I don't like trying to reverse bad decisions - it's pretty hard to do it well - but I really feel strongly about this one. (Interestingly, although I've heard many people criticising this choice, I don't actually remember hearing the C# team defending it. Given that reservations were raised back in 2005, when there was still plenty of time to change stuff, I suspect there are reasons no-one's thought of. I'd love to hear them some time.)

The goal would be to change from discovering extensions at a namespace to discovering extensions at a type level. (By which I mean at a "type containing extension methods" level - e.g. System.Linq.Enumerable or System.Linq.Queryably. Admittedly discovery on a basis which explicitly specifies the type to extend would also be interesting.) I don't mind exactly how the syntax works, but the usual ideas are ones such as:

static using System.Linq.Enumerable;
using static System.Linq.Enumerable;
using class System.Linq.Enumerable;

That's the easy part - the harder part would be working out the best way to phase out the "old" syntax. I would suggest a warning if extension methods are found and used without being explicitly mentioned by type. In C# 4 this could be a warning which was disabled by default (but could be enabled with pragmas or command line switches), then enabled by default in C# 5 (but with the same options available, this time to disable it). By C# 6 we could perhaps remove the ability to discover extension methods by namespace altogether, so the methods just wouldn't be found any more.

The C# team could be more aggressive than this, perhaps skipping the first step and making it an enabled warning from C# 4 - but I'm happy to leave that kind of thing to them, without paying it much more attention. I know how seriously they take breaking changes.

No CLR changes required as far as I can see.

Implicit "select" at end of query expressions

I can't say I've used VB9's LINQ support, but I've heard about one aspect which has some appeal. In C# 3, every query expression ends with either "select" or "groupby". The compiler is actually smart enough to ignore a redundant select clause (except for degenerate query expressions ) and indeed the language spec makes this clear. So why require it in the query expression in the first place? As a concrete example of before/after:

// Before
var query = from user in db.Users
            where user.Age > 18
            orderby user.Name
            select user;

// After
var query = from user in db.Users
            where user.Age > 18
            orderby user.Name;

This isn't a massive deal, but it would be quite neat. I worry slightly that there could be significant costs in terms of the specification complexity, however.

Internal members on internal interfaces

Interfaces currently only ever have public members, even if the interfaces themselves are internal. This means that implementing an internal interface in an internal class still means making the implementing method public, or using explicit interface implementation (which imposes other restrictions, particularly in terms of overriding). It would be nice to be able to make members internal when the interface itself is internal - either explicitly or implicitly. Implementing such members publicly would still be allowed, but you could choose to keep the implementation internal if desired.

This may require a CLR change - not sure.

"Namespace+assembly" access restriction

It's not an uncommon request on the C# newsgroup for the equivalent of C++'s "friend" feature - where two classes have a special relationship. In many ways InternalsVisibleTo is an assembly-wide version of this feature, but I can certainly see how it would be nice to have a slightly finer grained version. Sometimes two classes are naturally tightly coupled, even though they have distinct responsibilities. Although loose coupling is generally accepted to be a good thing, it's not always practical. At the same time, giving extra access to all the types within the same assembly can be a little bit much.

Instead of specifying particular types to share members with, I'd propose a new access level, which would make appropriately decorated members available to other types which are both within the same assembly and within the same namespace. This would be similar to Java's "package level" access (the default, for some reason) except without the implicit availability to derived types. (Java's access levels and defaults are odd to say the least.)

(Of course, this wouldn't help in assemblies which consisted of types within a single namespace.)

This would almost certainly require a CLR change.

InternalsVisibleTo simplification for strongly named assemblies

This one's just a little niggle. In order to use the InternalsVisibleToAttribute to refer to a strongly named assembly (which you almost always have to do if the declaring assembly is strongly named), you have to specify the public key. Not the public key token as the documentation claims, but the whole public key. Not only that, but you can't have any whitespace in it - so you can't use a verbatim string literal to easily put it in a block. Instead, you either have to have the whole thing on one line, or use compile-time string concatenation to make sure the key is still unbroken.

It's not often you need to look at the assembly attributes, so it's far from a major issue - but it's a mild annoyance which could be fixed with very few downsides.

This may require a CLR change - not sure.

Is that all?

I suspect that soon after posting this, I'll think of other ideas. Some may be daft, some may be more significant than these, but either way I'll do a new post for new ideas, rather than adding to this one. I'll update this one for typos, further explanations etc. I suspect if I don't post this now I'll keep tweaking it for hours - which is relatively pointless as I'm really trying to provoke discussion rather than presenting polished specification proposals.

Macros, and languages within languages

skeet — Fri, 08 Feb 2008 23:31:32 GMT

Ian Griffiths mailed me about macros, and explained how LISP macros were very different to C/C++ macros, working at a language level instead of at a text level. I won't pretend to understand all about what would be possible and what wouldn't, but Ian gave a good example: query expressions in C# 3. Instead of being part of the language itself, they could apparently have been written as macros, if C# supported them. Then if you wanted to have similar support for different forms of expression, you could just write your own macro library.

Assuming that's what people are actually requesting, I can certainly see the attraction - but I'd still prefer it if C# didn't go down that route. I'll go back to C++ for the guts of the reason why, but it's not really about macros at this point. It's about building your own language. Once, someone told me that C++ wasn't a language - it was a meta-language; no-one used "bare" C++, they worked out their own language made from the building blocks of normal C++, and then used that.

That may or may not be true - or more likely, it's true in some places but not others - but it scares me as an idea. I'm not going to claim I know every nuance of C#, but it's pretty rare that you'd throw a line at me without it being reasonably clear what's going to happen and why, at the language level. Extension methods might mean a bit more information is required as to where a particular method comes from, but it doesn't take a lot of digging to see what's going on.

Now imagine that C# 3 didn't include query expressions, but that someone had come up with them as a macro library. It's not an insignificant amount of effort to learn what's going on there, and how it all maps to normal method calls, potentially with expression trees as arguments instead of delegates. Until you understand what's going on at a reasonably deep level, you can't really make any firm decisions as to what code including a query expression will do. (Heck, that's one of the premises of the book: you should really know this stuff, or at least be aware of it.)

That's fine when there's a single macro library used globally, but now imagine every company has their own - or worse still, has a bunch of them grabbed from Code Project, possibly including a load of bugs. Most of us aren't accomplished language designers, and I suspect there'd be an awful lot of macro libraries out there which weren't quite thought through enough - but were still useful enough to be attractive. They'd become magnets for code warts.

It's hard enough when you change company to work out what 3rd party libraries are in use, how they're being used, what the coding conventions are etc. It would be much worse if I had to learn another flavour of C# itself each time. I'm already worried that developers are picking up C# 3 without having a firm enough grasp of C# 2 - and that's when there's just a progression within a single language.

I know this all sounds patronising and/or elitest and/or "nanny state" applied to programming languages - but it's how I feel nonetheless. I just don't think we (as a development community) are mature enough to handle that sort of power without it turning into a blood bath. This sort of thing sounds fabulous for hobby and research development, and would probably be great in the hands of the best few companies in the world - but I don't think it's a good idea for the mainstream.

Okay - time to hear why I'm wrong :)

C# 4, part 3: Ideas from Microsoft

skeet — Thu, 07 Feb 2008 23:11:37 GMT

Microsoft haven't committed to anything in C# 4 yet. However, there have been hints about what they've been considering in Eric Lippert's blog, and more than hints in Charlie Calvert's blog. There's not a lot to go on yet, but:

Immutability support

Most of Eric's posts about immutability have so far been about immutable data structures. However, the first post in the series did mention that they're playing around with immutability from the point of view of potential language support. Joe Duffy also wrote about immutability at roughly the same time.

What can we expect in terms of support? Possibilities:

Compiler checking via attributes, as per Joe's posts
Immutable collections to make it easier to sensibly embed collections within immutable types
Readonly automatic properties (as I mentioned in part 1 - I'll expand on this in the next post)

I'm not sure what could be usefully added beyond those. One possibility, however: what about automatic equality and hashcode generation? I touched on this last time when talking about "instant data types" but I don't see why it shouldn't be applicable in general. After all:

Immutable types are good candidates for dictionary keys - or to put it the other way round, using mutable types as dictionary keys is a risky idea
If all immutable types automatically override GetHashCode and Equals, and immutable types can only compose other immutable types, everything should just work
The obvious implementation of Equals and a "multiply, add, repeat" implementation of GetHashCode are pretty reasonable for many, many types. You could always manually override the methods if necessary.

One downside: Equality doesn't really work well when there's an inheritance hierarchy involved. Read Josh Bloch's "Effective Java" for a detailed discussion. (Ooh, new edition coming out soon. Should make for great reading.)

Generic variance support

Once again, Eric has posted rather a lot on this, concentrating on two aspects: interfaces and delegates. I believe these are already supported in the CLR (I'm sure interfaces are, and I suspect delegates are too).

Just to be clear, I don't think anyone should expect unsafe covariance/contravariance. The following code still won't compile (at least unless things go very differently to how I expect):

// Still won't work!
IList<string> strings = new List<string>();
IList<object> objects = strings;
objects.Add(new object()); // Oww!

This code, however, would be okay, due to the "readonly" nature of iteration:

// Should be okay - can't break type safety
IEnumerable<string> strings = new List<string>();
IEnumerable<object> objects = strings;

That's the interface side. For delegates, this would probably be possible:

// Contravariance of input parameters to delegates
Action<object> objectAction = (x => Console.WriteLine(x));
Action<string> stringAction = objectAction;

// Covariance of returns (and output parameters?) from delegates
Func<string> stringFunc = () => "foo";
Func<object> objectFunc = stringFunc;

All of this is conceptually good. It's more for people to understand, of course, but it's still a useful thing to have available.

Dynamic calling support

This one really surprised me - to the extent that I'll now need to edit the last chapter in the book so as not to look stupid when it's published. (It's fine to be wrong when predicting the future, but making a prediction which has already been proven false before publication is embarrassing.) I expected C# to stay fully static forever. However, it looks like the C# team is at least strongly considering making dynamic calling support available. Read the blog for more details, but note what isn't included: C# reacting dynamically. In other words, Ayende's beloved IDynamicObject support isn't being proposed (at the moment) - although I guess there's always a possibility that the DLR support will somehow be available through "normal" C# without extra compiler support.

This will disappoint some people of course, but I'm happy enough. I can't see myself using the new support particularly often, and I'm slightly worried at the extra complexity required in the language spec to explain what it will actually do, but I'm likely to treat it in roughly the same way as unsafe blocks - something to ignore most of the time.

Conclusion

As you can see, there's not a lot really on the table yet. That in itself is quite interesting, however - as well as the nature of the changes. I believe that the changes from C# 3 to 4 will be much more like those from 1 to 2 than 2 to 3. Think about when VS 2005 was released - C# 3 extensions were already available in CTP form for the VS 2005 beta. Here we are with VS 2008 having RTM'd a while ago, and we only have a few ideas to mull over. Now, I'm sure that there are implementations of all of the above features and almost certainly more - but they're not putting them out just yet. Hopefully we'll learn more over the next few months.

The big difference with C# 3 was that there was a grand plan: LINQ. Almost every feature in C# 3 (basically not automatic properties or partial methods) supports LINQ in some way or other. I don't see a big plan for C# 4. That's a very good thing, in my view. We need time - quite a lot of time, I suspect - to digest LINQ. Awful as the phrase is, LINQ has the potential to be a paradigm shift in development. Those shouldn't come along too often. Disparate changes can still be incredibly useful of course, so let's not lack ambition for C# 4 - but I'm expecting idiomatic C# 4 to still be roughly similar to idiomatic C# 3, which certainly couldn't be said of C# 3 to C# 2.

Only one more post in the immediate future: my own ideas for C# 4 (or at least those which I've come up with independently, even if others have mentioned them too).

C# 4, part 2: Ideas from other community members

skeet — Thu, 07 Feb 2008 21:01:00 GMT

There has been a fair amount of speculation online about what should be in C# 4. I've taken the list below from a few posts, primarily those by Ayende and Jeremy Miller. I've deliberately left out the ideas that Microsoft have mentioned that they're at least considering - they'll come in the next post.

Mixins

I suspect everyone has a different idea of what these mean, but I'll say what I'd like. I want to be able to implement an interface by proxying all calls (other than those I've actually implemented) to a particular member variable, as an aid to favouring composition over inheritance. As an example, here's a class which implements IList<string> but makes sure that only strings with length 5 or more can be added:

public class LongStringList : IList<string>
{
    [MixinImplementation(typeof(IList<string>))]
    readonly IList<string> m_list = new List<string>();

    public void Add(string item)
    {
        if (item.Length < 5)
        {
            throw new ArgumentException("Only strings of length >= 5 allowed");
        }

        m_list.Add(item);
    }
}

(Yes, you'd need to implement the setter as well to prevent other values being replaced. This is just sample code to give the rough flavour - and the syntax is pretty much made up as an example too. I'm not hung up on the syntax, I just want the functionality.

You could of course derive from System.ObjectModel.Collection<string> - but this prevents you from deriving from any other class, and fixes the inheritance forever. If you only really want to provide your clients with an IList<string> implementation, it's nicer not to pin anything down. At a later date you could manually implement more of the interface members instead of proxying them, without changing any of the calling code.

Symbols

I don't see the benefit over normal string interning here. That could just be because of a poor description of symbols in Ruby, admittedly... but I suspect any other benefit wouldn't meet the "it's got to be really useful in many situations" bar.

Hashes

I've only extensively used one language with hashes built in: Groovy. While I agree it's nice occasionally, I don't think it's worth bending the language out of shape for as we've now got collection initializers anyway:

var hash = new Dictionary<string,int>
{
{ "First", 1 },
{ "Second", 2}
};

Automatic delegation

To be honest I don't really know what Jeremy means here - although it's possible that he means what I understand as mixins. Ah the joys of loose terminology.

Metaprogramming

I only have vague ideas of what metaprogramming is all about, and those are mostly through Ayende's blog. I can see that it's almost certainly very powerful, but I'm not sure I want it in C#. I don't want C# to turn into a massive box with every nifty feature ever considered. It's possible I could be turned on this one, if someone showed me it working really nicely.

Macros

Ick, no. I've seen what macros tend to be used for. I'm sure there are nice shiny reasons for them, but certainly in the C/C++ form I'd be heavily against them.

Update: Ian Griffiths mailed me drawing my attention to LISP macros and how different they are to C/C++ macros. The way Ian described it sounds similar to what I understand of the metaprogramming that Ayende wants to do. I can see why it's a powerful tool... but personally I think I'd rather keep it away from a mainstream language like C#. I'll be writing another blog post to explain my view on this, because it's worthy of a much fuller discussion.

Everything virtual by default

Absolutely not! Yes, it would make mocking easier - but then making everything public by default would probably make things easier too. Inheritance is hard to control properly, and should only be done with very careful design. As I wrote in the previous post, I'd prefer classes to be sealed by default, i.e. a step in the opposite direction. Oh, there's the performance implication too, which is one of the reason's Java needs a much more complicated multi-pass JIT - to allow even virtual methods to be inlined until they're actually overridden. The performance part is much, much less important than the "inheritance is powerful but easy to misuse" argument.

Not only should the default not change at this point, but it was the right default to start with.

Instant Data Type

This would basically be a way of using anonymous types at a higher level - returning them with a return type of var, for instance. I don't support that proposal per se, but I can see a benefit in having "named anonymous types" - classes which have the same behaviour as anonymous types (in terms of immutability, equality, hash codes etc) but in a named manner. Something like this:

public class Person = new {string Name, DateTime DateOfBirth}
...
Person p = new Person { Name = "Jon", DateOfBirth = 19.June(1976) };
Person p2 = new Person { Name = "Jon", DateOfBirth = 19.June(1976) };

Assert.IsTrue(p.Equals(p2));
Assert.AreEqual(p.GetHashCode(), p2.GetHashCode());
// etc

Again, the syntax isn't terribly important to me - but the ability to define very simple immutable data objects is nice. It could also improve the readability of some LINQ code as you could make the meaning of the (currently anonymous) tuple clear in the name.

A few anticipated comebacks:

Clash with object initializers: yes, it looks like it's setting properties rather than passing them in as constructor arguments. That's unfortunate, and maybe parentheses would be better than braces here. That would require named parameters though. (I'll come onto those in another post!)
Why not just refactor the anonymous type to a named type? ReSharper lets you do this! Indeed it does - but then you've got a complete class to maintain. Given a single line of code, I know the features of the Person class. I can add a new property (breaking existing uses, of course) without having to make sure I get the equality and hash code implementations right manually, etc. I prefer simplicity of language expression over just saving typing by using snippets etc - that's why I like automatic properties.
It can't use quite the same implementation as anonymous types. Indeed, anonymous types are quite interesting in terms of the number of types actually generated in the IL, due to sharing of generics. I don't think it would be a great loss in this case though.
The use still isn't as brief as with anonymous types, due to needing to specify the name. True, but unavoidable, I think.

MemberInfo (infoof)

I don't think the C# team have actually stated that this is even potentially on the table, but one of the lovely things about having Eric Lippert as a tech reviewer for the book is I get to hear all kinds of anecdotes about what's been considered before. Some of them will be on the book's website in the notes section. In this case, I don't think it's a problem to reveal that the C# team have considered this before as an infoof operator (commonly pronounced "in-foof" of course).

I could go for this idea - it would certainly make reflection simpler in a number of cases.

Method Interception and IDynamicObject

I've lumped these two together as they're similiar (in my view) - they're leading down the road to a dynamic language. I can appreciate the benefits of dynamic languages, but that doesn't mean I think every language ought to be dynamic. I'd pass on these two.

Static interfaces

I'm not entirely sure what Ayende means on this front, but I know I've seen a number of requests for the ability to declare that a type definitely has a given static method. Indeed, I've wanted it myself a few times. However, I'm not sure how I'd go about using it. Interfaces by their current nature are used when we've got an instance. We already know how to pass references etc around - but not types, other than as either type parameters or Type objects.

Now, having just written it I wonder whether that's what Ayende means - if a type parameter is constrained to implement a particular interface, any static methods within that interface could be called using the type parameter. I can see the use in a few situations, but I'd need to be convinced that it was common enough to warrant a language change. The bar wouldn't be too high for me on this one though, as I think we could use very natural syntax without having to make up anything significantly new.

Aspect-Oriented Programming

Ooh, tricky one. I'm definitely undecided on this. I can see benefits, but also drawbacks in terms of how obvious the flow of the code is, etc - all the normal objections.

I think I'd welcome additions to the framework and/or runtime to make AOP support simpler, but then leave it to IoC containers etc to actually implement, rather than embedding AOP directly in the language.

Design by Contract

There are parts of DbC that I'd really like to see in the language, or possibly as a language/framework mixture where the framework describes certain common attributes (invariants, non-null arguments etc) and then each compiler takes note of the same attributes. I would really, really like to get rid of having manually-written trivial argument checking in my code. I don't think I'd immediately want to go as far as Spec# though, in terms of trying to deduce correctness. I wouldn't like to say why, beyond unfamiliarity (which I know isn't a good reason). Again, I could possibly be persuaded.

IDisposable implementation support

Good idea. It's a pain to implement IDisposable properly - some help would be welcome. It would probably need to be flexible enough to allow the developer to say whether a finalizer was required or not, and possibly some other things - but in principle, I'm in favour.

Constructor inheritance

Aargh, no. Constructors effectively belong to the type rather than instances of the type, so they're not inherited in the same way. They're a bit like static members - and I know we can call static members as if they were inherited as normal (e.g. UnicodeEncoding.ASCII), but it's generally a bad idea to do so in my view.

Also consider the lack of control. System.Object has a parameterless constructor - so should all types do so as well, given that they all inherit (directly or indirectly) from System.Object? What would new FileStream() really mean? I suppose one possibility would be to mark your type as intentionally inheriting constructors - which is all very well until the base class adds a new constructor you don't want, and you don't realise it until it's too late. On this one the complexities and disadvantages outweigh the advantages for me.

"Const correctness"

I haven't actually seen anyone asking for this specifically for C# 4, but it's been a general feature request pretty much forever. Again, I can see the benefits but:

I suspect it's the kind of thing you really need to get right in V1.0 for it to be genuinely useful.
I still haven't seen an easy way to express "this is an immutable reference to a mutable list of immutable objects of a particular type". Basically you need to express "constness" for every level down the composition hierarchy, which isn't simple.

Conclusion

Just to wrap the above up, here are the above features in "yes, maybe, no" categorization (just for my own view, of course):

Yes: Mixins, instant data types, IDisposable implementation, design by contract (partial), infoof
Maybe: Automatic delegation, metaprogramming, static interfaces
No: Symbols, hashes, everything virtual by default, macros, constructor inheritance, AOP, method interception and IDynamicObject

Next time (which may be tonight if I'm feeling energetic) I'll look at what Microsoft has hinted at.

C# 4, part 1: Looking back at the past

skeet — Tue, 05 Feb 2008 19:45:00 GMT

Everyone else is speculating about what's going to be in C# 4 (and various possibilities are coming out of MS), so I thought it would be wise to start my own series of wishlist posts before I miss the boat completely.

In this first post, I'm not going to look at the future at all - I'm going to look at mistakes of the past. When I say "mistake" I of course mean "things I would have done differently had I been a language designer with 20/20 hindsight". Of course, there's a lot of room for argument :)

Mistakes in C# 1

Lack of separate getter/setter access for properties. This came in C# 2, but it should have been obvious that it was highly desirable long before C# 1 came out.
Lack of generics - ish. Don't worry, I'm not going to claim that all the features of C# 2 and 3 should have been in C# 1, but if generics had been in at the start we could have avoided having the non-generic collections (and interfaces) completely. Mind you, I'm glad that the .NET team took their time instead of including the bodged (IMO) generics of Java 5.
Classes not being sealed by default. I've believed for a long time that allowing inheritance incurs a design cost (and it's not like I'm unique in that respect). C# fixed a mistake of Java by making methods non-virtual by default; the same should be true for classes in my view.
Enums just being named numbers. Again, I've blogged about this before, but it's worth mentioning again. It's possible to work around the lack of this feature (as the blog post readers pointed out!) but framework and language support would have been very welcome.
The "\x" character escape sequence. Fortunately it's rarely used, but it's so error-prone. Quick, how different are "\x8Good compiler", "\x8Bad compiler"? What's the first character in each string? (This will appear soon on my brainteasers page).
The switch statement. There are lots of ways in which this could have been better designed. VB addresses some of them (such as making it easier to express multiple matching values) but there are other ways in which this construct needed overhauling. Fallthrough is (rightly) prohibited, so why not just force braces round the code in the case block instead of requiring a break statement? Aside from anything else, that would fix the somewhat bizarre scoping rules.
Wacky overload resolution. I entirely understand the point that introducing new methods in a base type shouldn't change the behaviour in derived types - but if you've explicitly chosen to override that method, that should be more easily callable than it is. (See the first example of the brainteasers page to see what I'm talking about.)
The "lock" keyword, and associated issues. Basically, the IDisposable pattern should have been used for locking, and not every object should have a monitor associated with it. Developers should keep a close eye on what's being locked, and being able to lock on everything takes away from this. Likewise "lock" creates a keyword for little purpose (and one which would otherwise be useful as a variable name etc).

Mistakes in C# 2

Lack of partial methods. I'm really only saying this because it broke the format of C# in Depth slightly. I've introduced partial methods along with partial types because they logically fit in with them, and they don't fit in with any of the other features of C# 3 particularly. This is just a matter of not working out all of how partial types would be used - or at least not doing so early enough. (For all I know partial methods were on the table before C# 2 shipped - I wouldn't be surprised.)
Possibly the lack of generic variance. This is certainly a big issue of understanding which is often raised as a question. On the other hand, I suspect that if/when it becomes available, it will raise just as many questions in terms of the detail anyway...
The System.Nullable class. It's really only there as an historical accident, and I know it's not a C# issue as such - but even so... (Note for extra clarity - I'm fine with nullable types and the System.Nullable<T> struct. It's just the supporting class that I don't like.)
InternalsVisibleTo requiring the whole public key for strongly signed assemblies instead of the public key token (contrary to the documentation). Ick.

Mistakes in C# 3

It's a real shame that readonly automatic properties aren't in C# 3. I suspect they'll come in C# 4 (and they'll be on my wishlist in future posts) but I think it's reasonable to wonder why they weren't included in C# 3. Immutability is a known pattern of goodness, and although C# 4 may well contain any number of more significant improvements towards making it easier, readonly automatic properties would have been a good start.
The way that extension methods are found. This issue was raised time and time again before release, and I've never heard a good defence of finding them by whole namespace, instead of allowing developers to say "use the extension methods found in this class, please". As it is, anyone writing their own extension methods is likely to end up with whole namespaces devoted to a single type. It's very odd.

Of course that's not to say there aren't other things I'd like to see - but these are more "features which were slightly misdesigned" rather than "features which I really want".

I'm not trying to take anything away from the language designers - C# is still easily my favourite language in terms of its design, particularly in C# 3, but nobody's perfect :)

Next time I'll start giving my opinions of features that other people are calling for.