Mono.Upnp Dance Party

So it's been a while since mention was made of a certain UPnP library. What happened? First, I had various other things to do. Second, I decided to do two or three major refactorings, ditching a lot of code. Third, I moved development to github.

What the status?
The status? The status, you ask?! THIS is the status! If you can't see, I am pointing at my TV. My TV which is connected to my PS3. My PS3 which is playing music from my laptop computer with WIRELESS NETWORKING! Yes friends, tonight at last, Mono.Upnp and the PS3 are doing the DANCE OF LOVE. I plug, it plays. Universally. About ten minutes ago I finally tracked down the typo responsible for a day's worth of debugging and let me tell you, Starfucker never sounded so good (and they already sound so good anyway, seriously, you should listen to them).

What now?
I've kept pretty quite about the whole project because I wanted to lay all the groundwork before make too much noise. There is still work to be done on the core of the library, but now that it's working I'll start sharing more frequent updates. You can follow the project on github if you want commit-by-commit news.

Can I help?
Sure! But helping might be a little tricky. The solution only loads in MonoDevelop SVN, and there are certain necessary BCL fixes that require Mono from SVN too (one of them isn't even committed yet). It's not quite "checkout, compile, run," but if you're interested in helping out, I will be more than happy to get you up to speed. I wrote a TODO on the github wiki today with some stuff that needs doing. Testing is also something I will need help on. I don't have access to an XBox 360 anymore, so I'm going to need help on that front. As the library and the tools evolve, we'll need to test with as many devices as we can.

Yeah!
Yeah indeed! NOW DANCE!

C#er

Was chillin' with the impish abock last weekend when, all of a hullabaloo, he geniused something wonderful.

"Behold!" he cried:

var button = new Button {
    Label = "Push Me",
    Relief = ReliefStyle.None
};
button.Clicked += (o, a) => Console.WriteLine ("ouch!');

To which I replied, "?"

"Watch..." said he:

var button = new Button {
    Label = "Push Me",
    Relief = ReliefStyle.None,
    Clicked +=> Console.WriteLine ("ouch!")
};

"?!" came my response.

"Is not it better?"

"Yes," quoth I, "but gentle abock, this wundercode... it doth not compile!"

"... YET!"

Well friends, yet is over. I am here today to tell you that yes, IT DOTH COMPILE. This is what you get when Scott forgets to pull the git repos for his real projects before a plane flight: unsolicited language features. And there are other goodies:

As with anonymous methods via the delegate keyword, you may omit the parameters to a lambda if you aren't going to use them. This is also helpful when the delegate type has no parameters. For example:

Func<string> myFunc = () => "blarg";

Just look at those parenthesis! Chillin' there all higgledy piggledy. They look like some unseemly ASCII art. But now, presto chango:

Func<string> myFunc => "blarg";

See what I did there? That's called an assignment arrow. It is better. Don't argue with me, because you're wrong.

For my next trick, you can do the same kind of thing with lambdas and event handler registration.

myButton.Clicked +=> Console.WriteLine ("higgledy piggledy");

Because who ever uses the EventHandler arguments? A big, fat nobody, that's who.

Last but not least, you can now do all of this plus regular event handler registration inside of object initializers. abocks around the world rejoice!

There Is No Syntax Without Corner Cases

So there is at least one possible ambiguity with this new syntax:

class Foo {
    public void Add (Action<string> action) { ... }
    public Action<string> Bar { get; set; }
}

// Meanwhile, in some unsuspecting method:
var foo = new Foo {
    Bar => Console.WriteLine ("HELP ME!")
};

Question: Is that an object initialization, or a collection initialization?

Answer: It's ambiguous.

Solution: It's an object initialization. If you want it to be a collection initialization, throw some parenthesis around "Bar." This would be a good candidate for a compiler warning. And if you want to make it an unambiguous object initialization, you could do:

var foo = new Foo {
    Bar = () => Console.WriteLine (
        "What does this ASCII art even mean?")
};

Patch

The patch for all of this is available here. Apply to mcs, recompile, then use gmcs.exe passing -langversion:future.

Future

There has been on-again-off-again talk about adding non-standard language features to the C# compiler under the guard of -langversion:future. The main concern voiced is the ability to maintain such extensions. I will definitely discuss this patch with Marek and co. to see about landing it in mainline. I'll keep you up to date.

Are You Bock Enough?

In the meantime, I call upon manly man Aaron Bockover to make the only manly choice available: fork C# and ship the compiler. Because you're not really a serious media player until you have your own special language.

Casting Call

Type safety only gets you so far; eventually you have to cast. There are three features in the C# language which address typing: the unary cast operator and the binary "as" and "is" operators. I see people misuse these operators all the time, so here for your records are the official Best Ways to use each.

If you want to check the type of an object and do not care about using the object as that type, use the "is" operator. For example:

if (thing is MyType) {
    // do something which doesn't involve thing
}

If you want to check the type of an object and then use that object as that type, use the "as" operator and the check for null. For example:

var my_type_thing = thing as MyType;
if (my_type_thing != null) {
    // do something with my_type_thing
}

This only works for reference types since value types cannot be null. For value types, use the "is" and cast operators. For example:

if (thing is MyValueType) {
    var my_value_type_thing = (MyValueType)thing;
    // do something with my_value_type_thing
}

If you know for a fact that an object is some type, use the cast operator. For example:

var my_type_thing = (MyType)thing;
// do something with my_type_thing

These patterns minimize the operations performed by the runtime. This wisdom comes by way Marek who educated me on this a while ago. Please pass it on.

Dear LazyMarket

Are you hiring? Do you know someone who is hiring? Well you're in luck! Because none other than yours truly is looking for a job. If you're interested in how great I am, send an email to lunchtimemama@gmail.com and I'll get you a copy of my resume. I look forward to hearing from you...

Variance, Thy Name is Ambiguity

Previously
On This Blog...

"I love you, Generic Variance, and I want your babies RIGHT NOW!"

"I think there's something you should know about Generic Variance..."

"I can change him!"

And now, the thrilling continuation...

I've just sent my recommendation to the ECMA 335 committee regarding the generic variance problem. I present it here for your reading pleasure:

Quick Recap

The following is an example of an ambiguous circumstance involving generic variance, the very sort over which we have all lost so much sleep:

.class interface abstract I<+T> {
    .method public abstract virtual instance !T Foo ()
}

.class A {}
.class B extends A {}
.class C extends A {}

.class X implements I<class B>, I<class C> {
    .method virtual instance class B I[B].Foo () { .override I<class B>::Foo }
    .method virtual instance class C I[C].Foo () { .override I<class C>::Foo }
}

// Meanwhile, in some unsuspecting method...
I<A> i = new X ();
A a = i.Foo (); // AMBIGUITY!

Give a Runtime A Bone

To disambiguate such situations, we introduce a new custom attribute in the BCL. For the sake of example, let's call it System.PreferredImplementationAttribute. The PreferredImplementationAttribute is applied to a type and indicates which implementation should be selected by the runtime to resolve variance ambiguities. Our above definition of the type X would now look like this:

.class X implements I<class B>, I<class C> {
    .custom instance void System.PreferredImplementationAttribute::.ctor (class System.Type) = { type(I<class C>) }
    .method virtual instance class B I[B].Foo () { .override I<class B>::Foo }
    .method virtual instance class C I[C].Foo () { .override I<class C>::Foo }
}

New Rules

With the addition of this attribute, the runtime requires that any type defined in an assembly targeting the 335 5th edition runtime which implements multiple interfaces that are variants of a common generic interface MUST specify ONE AND ONLY ONE PerferredImplementationAttribute for EACH of the potentially ambiguous common interfaces, and that each such specification of a PerferredImplementationAttribute must reference an interface implemented by the type that is a legal variant of the ambiguous common interface. In other words, all possible ambiguities MUST be disambiguated by the use of PreferredImplementationAttribute custom attributes. If a type does not satisfy these rules, the runtime MUST throw a System.TypeLoadException.

As this rule only applies to assemblies targeting the new version of the runtime, old images will continue to execute without issue. If the committee prefers, the resolution of ambiguities in old types may remain unspecified, or alphabetical priority could be codified in the spec to standardize such behavior. I would be fine leaving it unspecified.

Custom Attributes vs. Metadata

Ideally, I feel disambiguation information belongs in the type metadata structure rather than a custom attribute. If the committee feels that amending the metadata specification is tenable, I would recommend doing so (though I don't have any thoughts at this time on the exact logical or physical nature of such an amendment). If, on the other hand, changing the metadata spec at this point in the game is not feasible, then a custom attribute will just have to do. I see the addition of one custom attribute type to the Base Class Library as entirely justified.

An Aside to Our Friends on the 334 Committee

As a note to language designers targeting the runtime, I personally would consider it obnoxious if developers where burdened with the manual application of such a custom attribute. C# and other languages would do well to prohibit the direct use of the custom attribute, favoring instead a special syntax to denote the preferred implementation (the "default" keyword comes to mind in the case of C#). If this committee changes the type metadata spec to include preferred implementation information (and does not introduce a custom attribute type for that purpose), then special language syntaxes will be necessary.

An Alternative

In the interest of completeness, I will describe an alternate (if similar) approach to the ambiguity resolution problem. Rather than annotate types to indicate which of their interface implementations will satisfy ambiguous calls, the preferred implementation could be denoted on a per-member basis. Referring again to our original type X, this solution would modify that type thusly:

.class X implements I<class B>, I<class C> {
    .method virtual instance class B I[B].Foo () { .override I<class B>::Foo }
    .method virtual instance class C I[C].Foo () {
        .override I<class C>::Foo
        .custom instance void System.PreferredImplementationAttribute::.ctor ()
    }
}

The member I[C].Foo is annotated with the System.PreferredImplementationAttribute, indicating that it will be selected by the runtime to fulfill otherwise ambiguous calls to I<T>.Foo. Note that in this solution the constructor to the PerferredImplementationAttribute type is parameterless. The runtime ensures that for EACH of the members of an interface which is the common variant of two or more of the interfaces implemented by a type, ONE AND ONLY ONE of the implementations for that member is flagged as "preferred."

Per-member preference definition affords developers more control but costs runtime implementers time, effort, and simplicity. I also don't envision many scenarios when developers would desire per-member control over implementation preference. I personally find this approach less tasteful than the per-interface solution but I mention it here, as I said, for completeness.

One More Thing...

There remains a situation on which there are varied opinions:

.class interface abstract I<+T> {
    .method public abstract virtual instance !T Foo ()
}

.class A {}
.class B extends A {}

.class X implements I<class A> {
    .method virtual instance class A I[A].Foo () { .override I<class A>::Foo }
}

.class Y extends X implements I<class B> {
    .method virtual instance class B I[B].Foo () { .override I<class B>::Foo }
}

// Meanwhile, in some unsuspecting method...
I<A> i = new Y ();
A a = i.Foo ();

In this situation I<A>::Foo is called on an object of type Y. There is an implementation of I<A>::Foo in Y's type hierarchy (X::I[A].Foo), but there is also an available implementation which is a legal variant of I<A> in Y itself (Y:I[B].Foo). Does the runtime favor the exact implementation, or the more derived variant implementation? I don't have strong feelings on the matter, but my slight preference is for favoring the exact implementation.

The runtime is deciding on behalf of the developer which implementation is most appropriate. It could be argued that an exact implementation, wherever it is to be found the type hierarchy, is more appropriate than a variant implementation.

Also - and this is an implementation detail which should not outweigh other considerations but may be useful to keep in mind if all other things are equal - Mono stores a type's implemented interfaces in a binary tree, meaning that finding an exact implementation is an O(log n) worst-case operation, whereas finding a legal variant interface among a type's implemented interfaces is an O(n) worst-case operation (all interfaces must be examined to see if a legal variant exists among them). I haven't heard of any way to do O(log n) (or better) lookup of variants. With such popular types as IEnumerable`1 becoming variant, the superior time complexity could make a difference.

Further Generic Variance Thoughts

I was writing a type today that implements both IDictionary<TKey, TValue> and ICollection<TValue>. These interfaces require the implementation of both IEnumerable<TValue> and IEnumerable<KeyValuePair<TKey, TValue>>. In .NET 4, the IEnumerable<T> type will be covariant. This exposes my type to potential ambiguity if it is assigned to a location of type IEnumerable<object> (see the previous post for details). If I were to follow my own advice and forbid the implementation of multiple interfaces which are variants of a single common interface, this type would be illegal. So on further reflection, I have decided to amend my opinion thusly: If there are multiple interface implementations which are variants of a common interface, then there must be implicit implementations of all of the potentially ambiguous members. These public members are then selected by the runtime to satisfy otherwise ambiguous calls. The implicit member implementations need not all be for the same interface. For example, if we have some interface IFoo<out T> with members T Bar(); and T Bat(); and we have some type with implements both IFoo<string> and IFoo<Uri>, it could have the members public string Bar(){} and public Uri Bat(){}. Any call to IFoo<object>.Bar() on an object of this type will execute the IFoo<string> implementation, and IFoo<object>.Bat() will execute the Uri implementation.

I believe that this restriction should be enforced at least at the language level (for all variant-capable languages targeting .NET), if not at the runtime level: all potentially ambiguous members must have public implementations. This resolves the ambiguity in a logical way, allows for more complex type design (which, as in the case of my type today, is desirable), and gives developers the ability to control which implementation will be selected. I think it is a Good Thing.

Who's Afraid of Generic Variance?

Abstract

This post is an in-depth exploration of generic variance in the ECMA 335 standard and the REALLY BIG PROBLEM therewith. See the previous post on generic variance for an introduction to the topic.

The Punchline

The ECMA 335 Standard, 4th Edition, allows for nondeterministic execution. This means that in certain situations involving generic variance, the specification does not provide sufficient guidance to resolve ambiguities. As you may imagine, nondeterminism is a Very Bad Thing in computing (usually). It means that your program may run one way on .NET 3.5 and another way on .NET 4 and a third way if Richard Stallman saw his shadow in the morning.

The Solution

The ECMA 335 committee is hoping to resolve this problem in the 5th edition. Unfortunately, no clear solutions have revealed themselves. There are a number of possible approaches, all of which have pros and cons. I will be describing the problems and their possible solutions in this post. Feel free to weigh in on the matter. A robust discussion will aid the 335 group in their decision.

The Implementation Selection Problem

There are a number of increasingly pointy corner cases, all variations on the same theme: which of multiple implementation does the runtime select for execution? I will describe these corner cases in order of ascending pointiness. For each case, I will propose a deterministic solution and then demonstrate how that solution fails to address the next corner case. (Note: the deterministic solutions I propose are merely examples. Other solutions could be used.)

Overview

Before getting into the corner cases, I will provide a broad overview of the problem. Ambiguous situations arise when there are multiple implementations of one generic interface (with different type arguments). The generic interface must have some variant generic type parameter.

Vocab

The implemented types are the closed generic interface types that are actually implemented in the type hierarchy of the object in question.

The execution type is the closed generic interface type of the location to which the object is assigned. Calls made to members of this type must be resolved to an implementation among the implemented types.

An exact implementation is the implementation of an implemented type whose generic type arguments precisely match those of the execution type. For example, if type A implements the generic interface I<String>, and we assign some A to an I<String> location, then its implementation for that interface is exact.

A variant implementation is the implementation of an implemented type whose generic type arguments do not precisely match those of the execution type, but are legal variants thereof. For example, if type A implements the covariant generic interface I<String>, and we assign some A to an I<Object> location, then its implementation for that interface is variant.

Case 0

Nothing to See Here

As a starting point, let us consider the following non-variant scenario which is NOT ambiguous.

interface I<T> {
    T Next();
}

class A {}

class X : I<A> {
    A I<A>.Next() {...}
}

class Y : X, I<A> {
    A I<A>.Next() {...}
}

// Test code
I<A> i = new Y();
A someA = i.Next();

Problem
There are two implementations of I<A>: one in X and one in Y. Which is used for the call to I<A>.Next()?

Solution
The implementation in type Y is used. As I said, this is not actually a problematic situation. I illustrate this case to demonstrate one of the ways the spec currently resolves potential ambiguities. In this case, the implementation in the most derived class is used. Y is more derived than X, therefore its implementation is used.

Case 1

Easy Pickins

interface I<out T> {
    T Next();
}

class A {}

class B : A {}

class X : I<A> {
    A I<A>.Next() {...}
}

class Y : X, I<B> {
    B I<B>.Next() {...}
}

// Test code
I<A> i = new Y();
A someA = i.Next();

Problem
There are two implementations which suffice for I<A>: the I<A> exact implementation in X, and the I<B> variant implementation in Y. Which does the runtime select?

Solution
There are two possible solutions. We could adopt the aforementioned "most derived implementation wins" rule, in which case the runtime would pick the variant implementation in Y.

The other solution is to favor exact implementations over variant implementations, in which case the runtime would pick the exact but less derived implementation in X.

For the sake of argument, let's adopt the second solution: the runtime will select the most-derived exact implementation if one exists.

Case 2

The Decider

interface I<out T> {
    T Next();
}

class A {}

class B : A {}

class C : B {}

class X : I<B> {
    B I<B>.Next();
}

class Y : I<C> {
    C I<C>.Next();
}

// Test code
I<A> i = new Y();

Problem
There is no exact implementation of I<A>. There are two variant implementations: I<B> in X and I<C> in Y. Which does the runtime select?

Solution
As before, there are two options. We could choose the most derived implementation, in which case the runtime would select the I<C> implementation in Y.

The other option is to select the variant implementation with the least "distance" to the execution type. We are attempting to select an implementation for I<A>. We have variant implementations I<B> and I<C>. B is nearer to A in the inheritance chain than is C. Therefore we say that I<B> has less "distance" to I<A> than does I<C>. It may therefore be the case that the I<B> implementation is a more relevant substitute for I<A> since B is nearer to A than is C. By this rule, we would select the less distant but less derived I<B> implementation in X.

There are problems with the second option. What if there are multiple type parameters, each with different distances? How do we calculate the total distance of the type? Such a solution could require a rather complex set of rules, complicating the specification and compliant runtimes. And at the end of the day, it is dubious whether "distance" is a meaningful selection criteria.

For the sake of argument, let us go with the first option: the runtime will select the most derived variant implementation in the absence of an exact implementation.

Case 3

Ambiguity is Scary

interface I<out T> {
    T Next();
}

class A {}

class B : A {}

class C : B {}

class X : I<B>, I<C> {
    B I<B>.Next () {...}
    C I<C>.Next() {...}
}

// Test code
I<A> i = new X();
A someA = i.Next();

Problem
There is no exact implementation for I<A> and there are two variant implementations, I<B> and I<C>, both defined in the same type: X. Which does the runtime select?

Solution
We are now approaching the point at which any selection rule is largely arbitrary. We can revisit the "least distant" option though its problems are no fewer. It is also unclear whether such a selection behavior is obvious to the user. The user may not have taken "distance" into consideration when designing their types. On the other hand, the user who wrote this code clearly failed to take a number of things into consideration and it's now the runtime's job to make the best possible choice. Anything is better than nondeterminism.

For the sake of argument, let us say that we select the variant implementation with the least distant type argument. If there are multiple type parameters, we take the distance from the first non-identical set of arguments.

Case 4

Sophie's Choice

interface I<out T> {
    T Next();
}

class A {}

class B : A {}

class C : A {}

class X : I<B>, I<C> {
    B I<B>.Next() {...}
    C I<C>.Next() {...}
}

// Test code
I<A> i = new X();
A someA = i.Next();

Problem
There is no exact implementation of I<A>. There are two variant implementations: I<B> and I<C>, both defined in type X. B and C are equidistant from A. What would Jesus do?

Solution
Select I<B>. Because B comes before C in the alphabet.

If you think that's heinously arbitrary, you're right! But remember our motto: anything is better than nondeterminism.

[UPDATE]
Several people have proposed selecting based on the order in which the implementations appear in the code. This would select I<B> because it is defined first. As I said, my solutions are merely example rules.

Recap

To review, our selection rules are:

1. The most derived exact implementation wins


2. Failing an exact implementation, the most derived variant implementation wins


3. If there are multiple equally-derived variant implementations and no exact implementation, the implementation with the least "distance" wins. If there are multiple type parameters, the distance is taken from the first non-identical set of arguments.


4. If there are multiple equally-derived equidistant variant implementations and no exact implementation, the implementation with alphabetical priority wins. If there are multiple type parameters, the alphabetical priority is taken from the first non-identical set of arguments.

How Arbitrary Is Too Arbitrary?

As the cases get cornerier, the solutions get arbitrarier. Somewhere around case 3, the arbitrariness begins to offend the delicate sensibilities. There are alternatives to arbitrary selection which I will describe in a moment but I would like to first emphasize the virtue of arbitrariness: it is better than nondeterminism. ANYTHING is better than nondeterminism. Eeny meeny miny moe is a step up from the current spec. If no other solution can be decided upon, egregious arbitrariness is still better than what we have.

As we consider alternatives to arbitrary selection, consider the question, "how arbitrary is too arbitrary?" For which of the above cases is one of the below alternatives a superior option? Bear it in mind as we press ahead...

Exceptions

Runtime exceptions are an alternative to arbitrary implementation selection. If an ambiguous situation arises, an exception pops up. The benefit of exceptions is that they let the developer know that there is an ambiguous situation, whereas arbitrary selection may simply lead to unexpected and difficult-to-debug behavior. There are two exceptional approaches:

Exception On Call

When an ambiguous call is made, throw a runtime exception. For example:

interface I<out T> {
    T Next();
}

class A {}

class B : A {}

class C : A {}

class X : I<B>, I<C> {
    B I<B>.Next();
    C I<C>.Next();
}

// Test code

I<A> i = new X();
A someA = i.Next(); // AMBIGUOUS CALL EXCEPTION HAPPENS HERE

This has the benefit of only throwing an exception if the ambiguity is actually going to be a problem. The major issue is, exceptions can be thrown from innocent code. If you pass an X to some library function which takes an I<A>, that library will blissfully call I<A>.Next() and trigger the exception. The stack trace will implicate the library, but the culprit is the X type definition.

Exception On Assignment

When an object is assigned to an ambiguous interface, throw a runtime exception. For example:

interface I<out T> {
    T Next();
}

class A {}

class B : A {}

class C : A {}

class X : I<B>, I<C> {
    B I<B>.Next();
    C I<C>.Next();
}

// Test code
I<A> i = new X(); // AMBIGUOUS ASSIGNMENT EXCEPTION HAPPENS HERE
A someA = i.Next();

This approach runs the risk of unnecessary exceptions. If an ambiguous call is never made, an ambiguous assignment is not dangerous. This approach also allows exceptions to be thrown from innocent code. If some library takes an I<B>, an X can be passed without ambiguity. The library is then at liberty to assign the I<B> to an I<A>, resulting in an exception. The library is not at fault, but the stack trace implies otherwise.

Invalid Ambiguity

Once you have answered the question "how arbitrary is too arbitrary," take everything on the "too arbitrary" side of the fence and make it against the rules. For example, if you conclude that there is no reasonable way of selecting between two variant implementations defined in the same type, then it would be invalid to define a type which implements multiple interfaces that are variants of a common interface.

This has the downside of invaliding currently valid CLI images. I don't know to what degree forward compatibility is a goal for the ECMA 335 spec.

Language-Level Enforcement

Irrespective of the runtime's solution to this problem, languages can impose independent restrictions on ambiguous type design. For example, C# could make it a compilation error for a type to implement multiple interfaces that are variants of a common interface, even if such a type is valid for the runtime. If all major languages enforce unambiguous type design, the pressure on the runtime to avoid arbitrariness is lessened since the dangerously arbitrary rules will not affect any code written in a major language. The only people vulnerable to the arbitrary rules are ostensibly savvy enough to be trusted with understanding obscure runtime behaviors.

The Least Worst Solution

There is clearly no silver bullet for the problem. The least worst solution will be a blend of several approaches. The appropriate blend will depend upon a number of things such as the importance of the forward compatibility of CLI images. The ultimate solution must address two concerns: the elimination of nondeterminism and the prevention of developer confusion. The same implementation must deterministically execute every time, and it must be clear to developers which implementation that will be.

My Thoughts

The implementation selections rules should begin as follows:

1. The most derived exact implementation wins.


2. In the absence of an exact implementation, the most derived variant implementation wins.

Situations not addressed by these rules are considered "ambiguous."

As a solution to ambiguous situations, exceptions serve neither of the stated goals. They achieve deterministic failure rather than deterministic execution and their stack traces obfuscate the root of the problem. A sufficiently descriptive error message could aid developer comprehension but it would be far too easy for a stack trace from "someone else's code" to become a bug report to the wrong people or an ignored problem. I think exceptions are the worst worst solution.

Language-level ambiguity preclusion is an very good idea but adding a compiler error for ambiguous type design could break existing code when existing interfaces are made variant. For example, consider this C#:

class A {}

class B : A {}

class C : A {}

class X : IEnumerable<B>, IEnumerable<C> {...}

This is currently a legal C# class definition. However with the release of .NET 4 the IEnumerable<T> interface will be made covariant, making the above class vulnerable to ambiguity. Making ambiguous type design a warning rather than an error would solve this problem but I think it is worth breaking existing code in the interest of drawing developers' attention to the new ambiguity.

All variance-capable .NET languages should add errors for ambiguous type design.

Which brings us to the question of the runtime's ambiguity handling mechanism. The two best options are:

1. Make ambiguities illegal.


2. Add an arbitrary implementation selection rule: alphabetical priority of type arguments.

Option 1 achieves both objectives of a solution: it guarantees deterministic execution and ensures developer comprehension by proscribing ambiguous circumstances altogether. However it also breaks the forward compatibility of existing binaries.

Option 2 guarantees deterministic execution but does not serve developer comprehension (no developer wants to consider the alphabetical priority of type arguments when designing their types). In conjunction with language-level enforcement, however, no developer should ever suffer this confusion. And this option affords all currently valid CLI images continued validity.

So the key question is, how important is compatibility?

I am tending toward option 1, but I think there is room for debate.

What Do You Think?

Comment away.

Next Time...

If all that weren't enough, there is a problem with variancifying existing types (such as turning IEnumerable<T> into IEnumerable<out T>) but I will save that for another post.

Thanks

Thanks goes to Dr. Nigel Perry on the ECMA 334 and 335 standards committee for working with me on this.