Is there any reason C# does not support manual inline methods? And what about optional parameters?

Question

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?

EDIT:

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.

Answer 1

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.

Answer 2

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.

EDIT:

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
{
    [System.Runtime.CompilerServices.MethodImplAttribute(MethodImplOptions.NoInlining)]
    private static void MyMethod()
    {
        //Powerful, magical code
    }

    //Other code
}

Answer 3

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:

For C#, inlining happens at the JIT level, and the JIT generally makes a decent decision.

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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).

Answer 8

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.

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...