This post originated from an RSS feed registered with .NET Buzz
by Eric Gunnerson.
Original Post: Q: Compiler compatibility vs. comformance
Feed Title: Eric Gunnerson's C# Compendium
Feed URL: /msdnerror.htm?aspxerrorpath=/ericgu/Rss.aspx
Feed Description: Eric comments on C#, programming and dotnet in general, and the aerodynamic characteristics of the red-nosed flying squirrel of the Lesser Antilles
I got an email from a customer today, in which he noted that the C# compiler allows
you to write:
bool b = ...
switch (b)
{
case true:
...
break;
case false:
....
break;
}
despite the fact that the spec does not list bool as one of the types
that you can switch on.
Unfortunately, we've shipped the current behavior, and one of our high-order goals
is not to break existing code by changing the compiler. In most cases, that's a really
good goal, as your customers are justifiably upset when the new compiler breaks their
code.
In this case, however, I think we may be going to far in not fixing a bug because
there's a chance somebody might have written code that used it. I'm therefore looking
for your opinion (noting, for the record, that it seems that I could sometimes be
replaced by an auto-blogger question-asking piece of software) on what makes the most
sense.
Question:
How would you have us trade off language conformance (and perhaps language innovation)
vs language stability?
More specifically, when is it acceptable for the compiler to give an error on code
that used to work?
Previous Topic
