No language has zero warts. I use it everyday, and love the language, and it's still sometimes painful to do good OO compared to Smalltalk. No meta classes sucks, static methods are a poor substitute, can't override them, can't call them on passed type references without reflection which is ugly. Multiple equivalent syntaxes for anonymous delegates is a wart, they should have just started with the shorter one. Foreach over a container lets you declare the wrong type and throws a runtime cast exception when it could often know at compile time that it's not valid.

Still, great language, love it.

> zero warts

C# is a nice language, but oh man, is that asking for it!

My pet example of a wart is the set of requirements on the iterated collection in foreach loops. Most C# developers probably think that the collection has to implement IEnumerable, but it is not so! I pasted the requirements from the spec at http://pastebin.com/EfsAmz6f

This is also a case where the dynamic type does something different than the static type. If you iterate over a statically typed non-IEnumerable collection, it will work fine (assuming it implements the required methods). But if you then change the type to dynamic, I think you get a runtime error.

So there's a wart for ya!

I was aware that something remotely similar is done when rewriting LINQ query expressions but I was not aware of this one. My first thought was that they added it to support dynamic and objects not implementing IEnumerable but as you mentioned exactly this seems to be the case where it would not work. I had a look at the C# 1.0 specification and it's already in there but a lot less verbose.

Any idea why they did this? The only thing this seems to achieve is that you can implement IEnumerable and IEnumerator without explicitly stating it. Are there any (common) classes to which this applies?

One big benefit of using structural (rather than nominal) typing in the foreach construct is that value types don't need to be boxed.

I am not sure about this - why would requiring an interface require boxing?

Interfaces are reference types and so if the GetEnumerator method on a struct is called through an interface then it must be boxed.

I see your point but I am not yet convinced. At least if the interface method is not explicitly implemented, I can call the same method not through the interface. But I don't know the specs well enough to judge if this would be a viable optimization avoiding boxing or if this could cause different behavior, for example if you start handing out the this pointer. Thinking a bit more about it, it probably does. Maybe I will have a closer look at this out of curiosity.

Yes, if the method is not explicitly implemented then you can call it without going through the interface.

But at that point it's just a regular method that might also happen to implement part of an interface that you the programmer are not using (at least at that point).

Likewise in the case of foreach, the compiler is looking for a particular method and does not need to care whether or not that method happens to also implement part of an interface, so there is not point in making the programmer go through the trouble of marking the type as such.

Collection initializers also do not need to be collections or anything. They just need to be init'ing a type that has IEnumerable and an Add function:

  class Heh : IEnumerable { 
   public void Add(object x) { Console.WriteLine(x); } 
   public IEnumerator GetEnumerator() { return null ; }
  }
  static void Main() { new Heh { "a", 1, DateTime.UtcNow }; } }

Prints out:

  a, 1, 6/25/2013 4:51:38 AM,

It might have been the right engineering approach all things considered. But having these special things that only the language can decide is annoying. The fewer the language primitives, the better.

It actually makes some sense - this is not a language primitive but syntactic sugar for a common task baked into the language. It's the same for using, foreach, events and link query expressions. In all cases you have to map the language construct to methods and properties.

Now you can argue whether it is better to just map to the methods Add<T>(T item), GetEnumerator<T>() and Dispose() or if you require an interface like IInitializable<T>, IEnumerable<T> and IDisposable. On one hand requiring an interface just adds some overhead, on the other hand it makes the intention much more explicit. They came up with different solutions for different cases - using requires the interface, foreach supports both ways and there is no interface for collection initializers.

I don't understand why foreach supports both ways - if I implement GetEnumerator() adding IEnumerable to the interface list seems no unreasonable requirement just like in the IDisposable case. I can understand that there is no interface for collection initializers because this feature was added in C# 3.0 and would have required adding an new interface to all existing collection classes, or changing interfaces or starting with an inconsistent implementation. Would be interesting to hear about the details of the decisions.

I'm arguing it's better to build the duck typing features that foreach and initializers use into the language itself. Every hard-coded keyword and to some extent, feature, is a strike against the language. foreach and stuff like that should be part of the stdlib.

But then you have to make the language and syntax flexible enough to deal with that – while also retaining ease of use, compilation speed (you don't want to go into C++ territory there) and perhaps other factors. All in all it's probably a tradeoff and regardless which way it sways, people are inconvenienced by it.

And arguably there are other languages which can and do fix that gap. Nemerle comes to mind. .NET allows you to mix languages freely so I think switching for parts where it makes sense isn't such a bad idea.

> No Anders & co didn't just add whatever they felt fashionable, they've designed a language over the course of a decade with (to my knowledge) zero warts...

There was definitely one that got me (they made a breaking change to fix it in C# 5.0, though).

http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi...

I agree completely, though, that it is remarkable how well-designed the language is.

Array covariance is another one. They added it because Java had it. And now they regret it.

Interesting. Did a Google search which turned up this explanation about why it's considered broken: array covariance means runtime type checks rather than compile-time checks, which are more expensive and could hide bugs that could be caught when compiling. (http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covar...)

I felt it compromised C++'s low level compatibility in exchange for increasingly verbose expressions. Perhaps C# has nothing to offer except for Microsoft's ecosystem. Valid in 2005 but not today.

I'm a die-hard C++ guy but years ago I wrote a few 10k's of C# and found it quite productive. Here's what I liked about it:

* Garbage collection

* Lightning fast compilation

* Pointer-safe subset good enough for most common uses.

LINQ is also considered a huge win by many, though I suspect it could also be done in C++.

Now if they just used the same compiler backend across their C++ and C# toolchains.

Well there is the managed C++ backend, if you're into that sort of thing. I've been known to use it once or twice. :-)

I did use it a few times, back when .NET was still beta. So I went through Managed C++ and C++/CLI transition.

I also find it nice that with C++/CX VC++ is offering what C++ Builder does for years in terms of C++ RAD development.

Nowadays most of the consulting projects I work on are in JVM and .NET land.

What I really wanted to say it that I would like to see NGEN and .NET JIT offer the same type of optimizations as VC++ does, like SIMD, auto-vectorization and such.

When targeting Windows Phone 8, .NET gets compiled to native code with such type of optimizations using a cloud based AOT compiler. Maybe those improvements will eventually be brought into the standard framework.

In C# you need to go pretty far out of your way to implement an exploitable codepath. (It's not _hard_, and I even found one due to the JIT.) But for almost all apps, the better security (and tooling), better turnaround, and, without opening an escape catch, verifiable type safety - that's pretty fantastic.

Can you please elaborate on the exploitable codepath you found that was due to the JIT? That sounds interesting!

This was in a early version of .NET, over a decade ago. Basically, certain calls in the CLR are marked in a special way so they can be done by internal CLR code instead of running managed code like any other function. I think Array.Copy is one example.

If you created a delegate (function pointer) to such a special function that hadn't been called yet, it'd point to the wrong place and let you do things that shouldn't be possible.

The neat thing is that the code was valid and verifiable (so it'd run in low-trust), but you'd still end up owning a function call to the wrong point of memory due to a runtime bug.

Like practically every CLR vuln, it's the loading platform that is affected, not the applications. I think it's only important when relying on the complicated sandboxing restrictions (CAS).

I'd like to publish a working example, but haven't had the time to figure out which old OS allows the specific old .NET version to replicate the behaviour. I only found it by accident and was more concerned about finding a workaround to not crash.

Did you report it and did it get fixed?

Yeah I had some friends and did an internal report. It's long fixed :)

Awesome, thank you.

I disagree with the "Microsoft platform" bit. The Mono/Xamarin guys have been coming up with a very nice competing/complementary platform. I've built personal and production projects running on Linux using Mono.

While I haven't used, the Xamarin iOS/Android development platforms look quite interesting. I suppose it has the stigma of a somewhat pricy per seat license but its likely worth it if you want to go with a shared codebase for iOS/Android/WP/Win8.

There's also MonoGame[1] which targets developers of MS's former XNA game dev kit.

[1]http://www.monogame.net/about