(You are currently looking at the first edition version of this page. This page is also available for the second and third editions.)

Notes for Chapter 7: Concluding C# 2: the final features

7.1.3: Partial method corner cases

Partial methods sound reasonably straightforward, don't they? Well, consider an expression tree which is built from a lambda expression which calls a partial method. If the partial method is removed, the lambda expression can't be converted into an expression tree any more, as there's no such thing as an expression tree which does absolutely nothing.

I'm so glad I don't write compilers.

7.2: Things the compiler won't spot

The C# team missed a few potential restrictions on static classes - things you can do but shouldn't really be able to. I suspect very few people have ever noticed this, but you can find the default value of a static class: default(MyStaticClass).

The compiler spots if you try to use this for type inference in the cases I've tried, but it's possible that you can trick it if you work hard enough.

7.2: Making a class static shows your intention

When describing static classes, I mostly stayed at the mechanical level of what they do, rather than why you'd want them to work that way. I did explain that it helps to keep the type from being misused, but Joe Albahari expresses an important reason much more elegantly:

I think static classes are important for clarity because [making a class static] states intention.

Exactly. Whenever there's a simple way of giving your reader a massive clue as to how you've designed your class to be used, that's a really good thing.

7.3: Choices of defaults

Eric's comment with respect to the choice of "the most private access available" as the default in C#:

This is in contrast to, say Jscript .NET, where the defaults are to make as many programs as possible work, so everything is public unless specified otherwise. The language goals of Jscript are different than those of C#.

7.3: Private - explicit or implicit?

I've already mentioned that Eric and I disagree over whether or not to include the private modifier when it's not needed. To refresh your memory, my point of view is that by omitting the modifier when something is as private as it can be, you draw attention to other members which are less private. Here's Eric's rebuttal:

By calling it out explicitly every time, I let the maintenance programmer who may not have the rules memorized know up front what the visibility is.

Also, making it explicit says "I made this private by design". If it is missing then you cannot tell whether it was private by design or by accident.

I'm not hugely worried by the first point, but the second is quite convincing. I'm still thinking it over, but I could end up changing my mind :)

7.5.1: Octal literals, warning pragmas, and \x escapes

Eric doesn't like lines such as #pragma warning disable 0169 - they provoke comments like this:

C# does not have octal literals, thank goodness, but this still gives me cognitive dissonance to look at. It reminds me too much of the painfully broken rules in Jscript for dealing with literals in this form...

I completely agree that it's a good thing that C# doesn't have octal literals. However, it does have the awful \x escape sequences for Unicode characters. Think fast - what's the difference between "I say:\x8Good compiler" and "You say:\x8Bad compiler"? Does one include "Good compiler" and the other include "Bad compiler" in its output? No - because while "G" isn't a valid hex digit, all the characters in "Bad" are. The two literals are the same as : "I say:\u0008Good compiler" and "You say:\u8BAD compiler" - but here the difference is much more obvious.