Future-Proofing A Design

Last time on FAIC a user asked for guidance on the potential pitfalls of refactoring an automatic property into a regular explicit property. This is just an example of a far more general problem: how can we design programs so that they are easy to get right when things inevitably change in the future? This…

9

Automatic vs Explicit Properties

Here’s a question I got from a C# user last year, a question I get fairly frequently: User: With “regular” explicit properties, I tend to use the private backing field directly from within the class. Of course, with an automatic property, you can’t do this. My concern is that in the future, if I decide…

16

Why Can’t I Access A Protected Member From A Derived Class, Part Two: Why Can I?

This is a follow-up to my 2005 post on the same subject  which I believe sets a personal record for the longest time between parts of a series. (Of course, I didn’t know it was a series when I started it.) Please read the previous article in this series, as this post assumes knowledge of…

38

Covariance and Contravariance in C#, Part Nine: Breaking Changes

Today in the last entry in my ongoing saga of covariance and contravariance I’ll discuss what breaking changes adding this feature might cause. Simply adding variance awareness to the conversion rules should never cause any breaking change. However, the combination of adding variance to the conversion rules and making some types have variant parameters causes…

34

Future Breaking Changes, Part Three

As I said earlier, we hate causing breaking changes in our product, the C# compiler, because they cause our customers pain. Said customers are also software developers, and presumably they hate causing breaking changes for their customers as much as we do. We want to throw our customers into the Pit of Success and give…

21

Future Breaking Changes, Part Two

Last time I mentioned that one of the subtleties of programming language design is weighing the benefit of adding a feature against the pain it will cause you in the future. This is a specific subset of a more general set of problems. Languages run into the same problem that other large, multiply-versioned software products run…

9

Future Breaking Changes, Part One

We on the C# team hate making breaking changes. As my colleague Neal called out in his article on the subject from a couple years ago, by “breaking change” we mean a change in the compiler behaviour which causes an existing program to either stop compiling entirely, or start behaving differently when recompiled. We hate…

14

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()); It should be clear why this produces an exception at runtime; the user-defined operator returns a Base and that…

8

Odious ambiguous overloads, part two

There were a number of ideas in the comments for what we should do about the unfortunate situation I described yesterday. We considered all of these options and more.  I thought I might talk a bit about the pros and cons of each. I suggested do nothing.  We shipped with this behaviour in C# 2.0,…

9

Odious ambiguous overloads, part one

As you might have gathered, a lot of the decisions we have to make day-to-day here involve potential breaking changes on odd edge cases. Here’s another one. Consider the following terrible but legal code: public interface I1<U> {    void M(U i);    void M(int i);} My intense pain begins when the user writes: public class C1 :…

9