April 2007 - Posts

• Even More Conversion Trivia

  I learn something new about C# every day. This is a subtle and tricky language. Pop quiz: foo is of a type which has a base class which has made a normal, everyday virtual override of System.Object.ToString . There are no additional overrides, hides, Read More... Posted Monday, April 30, 2007 2:10 PM by Eric Lippert | 13 Comments Filed under: C#, Puzzles

• Write-only variables considered harmful? Or beneficial?

  I haven't forgotten that I promised to describe one more place where we insert an explicit conversion automatically. But before that, a quick digression. Reader Phil Haack has written some good tips for writing clear code and quotes an old post of mine Read More... Posted Monday, April 23, 2007 7:00 AM by Eric Lippert | 13 Comments Filed under: C#, Code Quality

• Chained user-defined explicit conversions in C#, Part Three

  Jeroen Frijters knew the answer to my challenge of last time: how is it that Foo foo = new Foo(); can cause a runtime conversion failure? And how is it that Bar bar = (Bar)(new Baz()); can succeed even if there is no user-defined conversion or built-in Read More... Posted Friday, April 20, 2007 7:00 AM by Eric Lippert | 2 Comments Filed under: COM Programming, C#, Puzzles, Conversions

• Chained user-defined explicit conversions in C#, Part Two

  Reader Larry Lard asks a follow-up question regarding the subject of Monday’s blog entry . Why is it that the compiler knows that (int)(new Base()) will always fail, and therefore makes the conversion illegal, but does not know that (Derived)(new Base()) Read More... Posted Wednesday, April 18, 2007 7:00 AM by Eric Lippert | 9 Comments Filed under: C#, Puzzles, Conversions

• Chained user-defined explicit conversions in C#

  Reader Niall asked me why the following code compiles but produces an exception at runtime: class Base {} class Derived : Base {} class Castable { public static explicit operator Base() { return new Base(); } } // ... Derived d = (Derived)(new Castable()); Read More... Posted Monday, April 16, 2007 7:00 AM by Eric Lippert | 8 Comments Filed under: C#, Breaking Changes, Conversions

• News flash: Instances of anonymous types will be immutable

  I've been meaning to write a blog post about a recent design change that we've made here on the C# team. As you may have gathered from my previous posts, we are introducing anonymous tuple types in C# 3.0. We've recently decided to make instances of those Read More... Posted Friday, April 13, 2007 10:11 AM by Eric Lippert | 11 Comments Filed under: C#

• Practice thinking like a compiler tester, part three

  Yesterday I posed a slightly harder version of the puzzle I posted the day before . Reader Steve found a solution: public class C : A {} public class A { public class D : C {} } See his comment for the trace of the logic that shows why this asserts. The Read More... Posted Thursday, April 12, 2007 7:00 AM by Eric Lippert | 1 Comments Filed under: C#, Puzzles

• Practice thinking like a compiler tester, part two

  Reader RichM found the same solution to the puzzle I posed yesterday that I did: public class V : S.T {} public class S { public class T{} } The control flow of the emitter from the start to the point of the bug goes like this: Emit(V) Emit (S.T) // V Read More... Posted Wednesday, April 11, 2007 7:00 AM by Eric Lippert | 5 Comments Filed under: C#, Puzzles

• Practice thinking like a compiler tester

  I don’t know why but for some reason I find this little recursive algorithm I ran across in the compiler the other day to be completely hilarious. For every class in your program we have to emit metadata. For various historical reasons, there are strict Read More... Posted Tuesday, April 10, 2007 12:03 PM by Eric Lippert | 13 Comments Filed under: C#, Puzzles