C# 3.0 Collection Initializers, Duck Typing and ISupportsAdd

Ilya Ryzhenkov from the ReSharper team has an interesting post: C# 3.0 Collection Initializers - Incomplete Feature? The problem is:

... restrictions are too strong - type being constructed should implement IEnumerable and have instance method "Add". IEnumerable is not of a big deal, but inability to use extension methods for Add is deal breaker.

I think that Ilya makes a very good point and that this feature indeed could be made more universally applicable. However, it is important to clearly understand the semantics of this feature to use it correctly - developers should know precisely what happens behind the curtains, otherwise unexpected side-effects can occur.

Now let's brainstorm a little bit. Recently I wrote about more fine-granular interfaces. I exaggerated a little, but the idea was that an interface should define a minimal contract. Specifically, I expressed regret that there is no ISupportsAdd interface, because adding stuff is a widely used ability of many entities, not necessarily collections.

I think it would help a lot if we had an ISupportsAdd/ISupportsAdd<T> interface with the only void Add(T item) method (you could also name it IFillable, IAllowsAdd, ICanAdd, you name it). For places in the framework where Add methods are named differently (e.g. AddPermission), this interface could be implemented explicitly.

This leads us to another problem: there are already lots of shipped types that do not implement this "ISupportsAdd" interface. How to add an implementation of an interface to a type without changing the type (and its declaring assembly)? We'd need something like extension methods ("extension interfaces", anyone?). Orion Edwards makes (in my opinion) a terrific suggestion:

Define an alternative to an interface called "requirement". It would work and behave exactly the same as an interface EXCEPT that it would use duck typing instead of static typing. For example:

public requirement Closeable
{
    void Close();
}

public void TestMethod( Closeable c )
{
    c.Close();
}
TestMethod( new System.Windows.Forms.Form() );

Collection initializers are another case where duck typing is sneaking into the C# language. Guess what the first case is? Right, the foreach statement. I was surprised, too, when I read a post by Krzysztof Cwalina about Duck Notation. It turns out, foreach doesn't necessarily require IEnumerable - it can also use duck typing to recognize iterable entities.

However, I'm not a professional language designer and I have no idea how duck typing would behave in a statically typed language. The known problem with duck-typing is that it orients to spelling of members, and not the semantics. There could be cases where members are named equally but have totally different semantics, so duck-typing would destroy the benefits of static type checking by allowing semantically incompatible assignments. But with this explicit "requirement" duck typing, who knows, maybe it's a good idea.

I'm just saying that I already had a lot of cases where I regretted that a shipped type doesn't implement some interface - and I couldn't add this interface to the type declaration because I'm the consumer, and not the producer of the type. I believe that "Extension interfaces" or "explicit duck typing" would really help here.

P.S. Oh, and can anyone explain why do we need to implement IEnumerable to be able to use collection initializers? I'm probably overseeing something obvious, but I thought I'd take the risk of sounding stupid and ask anyway :)

Links:
On duck typing in .NET see also:

• IHttpContext And Other Interfaces For Your Duck Typing Benefit
• http://tomasp.net/articles/ducktyping-in-phalaner.aspx
• Duck Typing