Browse by Tags

• Brittle Base Classes
• C# 4.0
• closures
• Code Generation
• Code Quality
• coin flipping
• Conversions
• Covariance and Contravariance
• definite assignment
• foreach
• keywords
• Lambda Expressions
• Language Design
• Memory Management
• Overload Resolution
• protected
• Scripting
• Security
• Software development methodology
• Value Types

• Closing over the loop variable, part two

  Thanks to everyone who left thoughtful and insightful comments on last week's post. More countries really ought to implement Instant Runoff Voting; it would certainly appeal to the geek crowd. Many people left complex opinions of the form "I'd prefer Read More... Posted Monday, November 16, 2009 8:18 AM by Eric Lippert | 45 Comments Filed under: C#, Breaking Changes, Lambda Expressions, foreach, closures, coin flipping

• Closing over the loop variable considered harmful

  I don't know why I haven't blogged about this one before; this is the single most common incorrect bug report we get. That is, someone thinks they have found a bug in the compiler, but in fact the compiler is correct and their code is wrong. That's a Read More... Posted Thursday, November 12, 2009 6:50 AM by Eric Lippert | 124 Comments Filed under: C#, Breaking Changes, Lambda Expressions, Language Design, foreach, closures

• The void is invariant

  [UPDATES below] A while back I described a kind of variance that we’ve supported since C# 2.0. When assigning a method group to a delegate type, such that both the selected method and the delegate target agree that their return type is a reference type, Read More... Posted Monday, June 29, 2009 7:30 AM by Eric Lippert | 19 Comments Filed under: Scripting, C#, Breaking Changes, Code Generation, Conversions, Covariance and Contravariance, Memory Management

• Reserved and Contextual Keywords

  Many programming languages, C# included, treat certain sequences of letters as “special”. Some sequences are so special that they cannot be used as identifiers. Let’s call those the “reserved keywords” and the remaining special sequences we’ll call the Read More... Posted Monday, May 11, 2009 8:07 AM by Eric Lippert | 11 Comments Filed under: C#, Breaking Changes, C# 4.0, Language Design, keywords

• 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 Read More... Posted Friday, January 16, 2009 9:21 AM by Eric Lippert | 9 Comments Filed under: C#, Breaking Changes, Code Quality, Software development methodology

• 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 Read More... Posted Wednesday, January 14, 2009 9:11 AM by Eric Lippert | 16 Comments Filed under: C#, Breaking Changes, Code Quality

• 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, Read More... Posted Friday, March 28, 2008 4:30 PM by Eric Lippert | 36 Comments Filed under: Security, C#, Breaking Changes, protected

• 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 Read More... Posted Friday, November 02, 2007 7:33 AM by Eric Lippert | 34 Comments Filed under: C#, Breaking Changes, Covariance and Contravariance, C# 4.0

• 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 Read More... Posted Tuesday, September 04, 2007 7:30 AM by Eric Lippert | 21 Comments Filed under: C#, Breaking Changes, Brittle Base Classes

• 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 Read More... Posted Friday, August 31, 2007 7:00 AM by Eric Lippert | 9 Comments Filed under: C#, Breaking Changes, Lambda Expressions, Overload Resolution

• 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 Read More... Posted Thursday, August 30, 2007 7:00 AM by Eric Lippert | 14 Comments Filed under: C#, Breaking Changes

• 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

• 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 Read More... Posted Thursday, April 06, 2006 10:13 AM by Eric Lippert | 9 Comments Filed under: C#, Breaking Changes

• 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 Read More... Posted Wednesday, April 05, 2006 8:58 AM by Eric Lippert | 9 Comments Filed under: C#, Breaking Changes, Overload Resolution

• The Root of All Evil, Part Two

  There were a number of interesting comments to yesterday's posting about premature optimization. Several readers pointed out that there are various options we could take: Do nothing. Maintain backwards compatibility and spec incompatibility. Change the Read More... Posted Wednesday, March 29, 2006 2:45 PM by Eric Lippert | 7 Comments Filed under: C#, Breaking Changes