Take the 2-minute tour ×

Is there any design reason for that(like the reason they gave up multi inheritance)?

or it just wasn't important enough?

and same question applies for optional parameters in methods... this was already in the first version of vb.net... so it surely no laziness that cause MS not to allow optional parameters, probably architecture decision.. and it seems they had change of heart about that, because C# 4 is going to include that..

Does anybody know what was the decision and why did they give it up?


Maybe you didn't fully understand me. I'm working lately on a calculation program (support numbers of any size, to the last digit), in which some methods are used literally millions of times per second.

Say I have a method called Add(int num), and this method is used quiet a lot with 1 as parameter (Add(1);), I've found out it is faster to implement a special method especially for one. And I don't mean overloading - Writing a new method called AddOne, and literally copy the Add method into it, except that instead of using num I'm writing 1. This might seems horribly weird to you, but it actually faster.

(as much as ugly it is)

That made me wonder why C# doesn't support manual inline which can be amazingly helpful here.

thanks. (and why did you vote me down :S)

Edit 2:

I asked myself whether or not to add this. I'm very well familiar with the weirdness (and disadvantages) of choosing a platform such as dot net for such project, but I think dot net optimizations are more important than you think... especially features such as Any CPU etc.

share|improve this question
System.Numerics.BigInteger in .NET 4.0: msdn.microsoft.com/en-us/library/… –  Dan Oct 25 '09 at 19:01
Man don't ruin it for me! –  Letterman Oct 25 '09 at 19:30
@Itay: are you sure your issues are related to the lack of inlining? You haven't implemented inlined operations with your special AddOne() method. Try doing so and evaluating the perf differences. Also, are you sure the JIT isn't inlining for you? Have you looked at the IL? –  Michael Petrotta Oct 25 '09 at 19:33

8 Answers 8

up vote 6 down vote accepted

To answer part of your question, see Eric Gunnerson's blog post: Why doesn't C# have an 'inline' keyword?

A quote from his post:


EDIT: I'm not sure of the reason for delayed optional parameters support, however saying they "gave up" on it sounds as though they were expected to implement it based on our expectations of what other languages offered. I imagine it wasn't high on their priority list and they had deadlines to get certain features out the door for each version. It probably didn't rise in importance till now, especially since method overloading was an available alternative. Meanwhile we got generics (2.0), and the features that make LINQ possible etc. (3.0). I'm happy with the progression of the language; the aforementioned features are more important to me than getting support for optional parameters early on.

share|improve this answer
yeah but sometimes it doesn't! i don't merely ask this question, sometimes you need it~ –  Letterman Oct 25 '09 at 18:42
@Itay: can you provide an example where inlining would have helped you, and the JIT didn't didn't do it for you? Also, did you read Eric's post? –  Michael Petrotta Oct 25 '09 at 18:44
@Itay: use the right tool for the right job; if performance is really that important, write that section of code in (unmanaged) assembly/C/C++ and call into it from C# (perhaps via C++/CLI). –  Dan Oct 25 '09 at 18:47

Manual inlining would be almost useless. The JIT compiler inlines methods during native code compilation where appropriate, and I think in almost all cases the JIT compiler is better at guessing when it is appropriate than the programmer.

As for optional parameters, I don't know why they weren't there in previous versions. That said, I don't like them to be there in C# 4, because I consider them somewhat harmful because the parameter get baked into the consuming assembly and you have to recompile it if you change the standard values in a DLL and want the consuming assembly to use the new ones.


Some additional information about inlining. Although you cannot force the JIT compiler to inline a method call, you can force it to NOT inline a method call. For this, you use the System.Runtime.CompilerServices.MethodImplAttribute, like so:

internal static class MyClass
    private static void MyMethod()
        //Powerful, magical code

    //Other code
share|improve this answer
I think parameter names are as important as method names to a public interface. Changing method names always broke code, now changing parameter names does too. It's obviously better not to break if it can be avoided, but with proper design it should be possible to have your parameter names be as stable as your method names. –  Joren Oct 25 '09 at 18:57
I don't speak about the names of parameters. For an optional parameter, you have to specify a standard value for this parameter, and if you change this standard value, you have to recompile every consuming assembly for it to use the new value instead of the old, because the values are copied at the call site. –  Maximilian Mayerl Oct 25 '09 at 19:01
Ah, I misunderstood what you meant by "because I consider them somewhat harmful because the parameter get baked into the consuming assembly". I thought you were talking about parameter names there. –  Joren Oct 25 '09 at 19:02
... although parameter names are important due to named arguments. They've always been important in .NET depending on the language you use, but now they're important when writing just C# too. –  Jon Skeet Oct 25 '09 at 19:35

My educated guess: the reason earlier versions of C# didn't have optional parameters is because of bad experiences with them in C++. On the surface, they look straight-forward enough, but there are a few bothersome corner cases. I think one of Herb Sutter's books describes this in more detail; in general, it has to do with overriding virtual methods. Maximilian has mentioned one of the .NET corner cases in his answer.

You can also pretty much get by with out them by manually writing multiple overloads; that may not be very nice for the author of the class, but clients will hardly notice the difference between overloads and optional parameters.

So after all these years w/o them, why did C# 4.0 add them? 1) improved parity with VB.NET, and 2) easier interop with COM.

share|improve this answer


Then you chose a wrong language. I assume you actually profiled your code (right?) and know that there is nothing apart from micro-optimisations that can help you. Also, you're using a high-performance native bigint library and not writing your own, right?

If that's true, don't use .NET. If you think you can gain speed on partial specialisation, go to Haskell, C, Fortran or any other language that either does it automatically, or can expose inlining to you to do it by hand.

If Add(1) really matters to you, heap allocations will matter too.

However, you should really look at what the profiler can tell you...

share|improve this answer

C# has added them in 4.0: http://msdn.microsoft.com/en-us/library/dd264739%28VS.100%29.aspx

As to why they weren't done from the beginning, its most likely because they felt method overloads gave more flexibility. With overloading you can specify multiple 'defaults' based on the other parameters that you're taking. Its also not that much more syntax.

share|improve this answer

Even in languages like C++, inlining something doesn't guarantee that it'll happen; it's a hint to the compiler. The compiler can either take the hint, or do its own thing.

C# is another step removed from the generated assembly code (via IL + the JIT), so it becomes even harder to guarantee that something will inline. Furthermore, you have issues like the x86 + x64 implementations of the JIT differing in behaviour.

share|improve this answer

To add to previous answers: Making a method private static would be closest to an "inline" keyword in JIT's terms.

share|improve this answer
Isn't JIT inlining purely a call site consideration? Obviously virtual methods can't be inlined, but otherwise it shouldn't really matter what kind of method it is, right? –  Joren Oct 25 '09 at 18:58

Java doesn't include an inline keyword either. The better Java JITs can inline even virtual methods, nor does the use of keywords like private or final make any difference (it used to, but that is now ancient history).

share|improve this answer

Your Answer


