Optional Named Parameters in C# 4.0

  • Thread starter Thread starter cody
  • Start date Start date
C

cody

If I understand it correctly Microsoft implemented them by just filling
in the missing parameters as fixed values in the call site at compile time.

public class TextBoxInfo
{
public TextBoxInfo(
string text = "",
float size = 10.0f,
float width = 50.0f)
{
..
}
}

Currently a call to new TextBoxInfo(size: 35f) is compiled to:

new TextBoxInfo("", 35f, 50f)

So if the default value of a parameter is changed, the clients has be be
recompiled, otherwise we have a discrepancy here.
Wasn't this exactly the reason why they didn't include optional
parameters in the first place, because they couldn't solve this problem?

Why doesn't the compiler do it this way:

It should insert in the class where the method is defined 'unspeakable'
(that is you cannot use them in code directly by yourself) static
readonly fields which are containing the default values for the optional
parameters so the call will be converted to something like that:

new TextBoxInfo(TextBoxInfo.defaultvalue$ctor$text, 35f,
TextBoxInfo.default$width)

There should not be so much impact to performance, the code should
instead by smaller because you not only have references to the values
not the values itself hardcoded in the call.

What do you think about it?
 
If I understand it correctly Microsoft implemented them by just filling
in the missing parameters as fixed values in the call site at compile time.
So if the default value of a parameter is changed, the clients has be be
recompiled, otherwise we have a discrepancy here.
Why doesn't the compiler do it this way:

It should insert in the class where the method is defined 'unspeakable'
(that is you cannot use them in code directly by yourself) static
readonly fields which are containing the default values for the optional
parameters so the call will be converted to something like that:

new TextBoxInfo(TextBoxInfo.defaultvalue$ctor$text, 35f,
TextBoxInfo.default$width)

There should not be so much impact to performance, the code should
instead by smaller because you not only have references to the values
not the values itself hardcoded in the call.

What do you think about it?
Click to expand...

I believe the main reason why C# 4.0 implements optional arguments the
way it does is because CLI specification already has a standardized
facility for optional arguments, and that's how it works. VB also uses
it, so as long as C# sticks to it, you could call VB methods with
optional arguments from C#, and vice versa (and, of course, this is
also applicable to any other .NET language that would also use CLR
facilities for optional arguments).
 
Peter said:
I'm not sure that's correct. The default values are filled in "at
compile time", but in C# it's important to know which "compile time"
you're talking about.

My understanding is that the C# compiler generates a code attribute
specifying the default value. Then the JIT compiler is what fixes up
the actual call site to use the correct default value.

At least, that's how I read this recent blog post from Sam Ng:
http://blogs.msdn.com/samng/archive...ts-optional-arguments-and-default-values.aspx
Click to expand...


Thanks this blog seems to describe it in more depth than the ones I've
read.
 
Pavel said:
I believe the main reason why C# 4.0 implements optional arguments the
way it does is because CLI specification already has a standardized
facility for optional arguments, and that's how it works. VB also uses
it, so as long as C# sticks to it, you could call VB methods with
optional arguments from C#, and vice versa (and, of course, this is
also applicable to any other .NET language that would also use CLR
facilities for optional arguments).
Click to expand...

Thanks I didn't know that VB already did it in exactly the same way.
Now it makes (more) sense to me.
 
My understanding is that the C# compiler generates a code attribute  
specifying the default value.  Then the JIT compiler is what fixes up the  
actual call site to use the correct default value.

At least, that's how I read this recent blog post from Sam Ng:http://blogs.msdn.com/samng/archive/2009/02/03/named-arguments-option...
Click to expand...

That's not how I read it:

"First we need to note that the use of optional arguments is really
just syntactic sugar. The compiler cannot generate a call without
actually providing all the arguments - it simply provides an argument
for you and allows you to omit specifying it.

Once the compiler realizes that you're calling a method and omitting
an argument because it is optional, it takes the value specified in
the DefaultParameterValueAttribute and encodes that as a constant
value for the argument that you've omitted."

Note that "compiler" here is clearly "C# compiler", not "JIT
compiler", as it was fully spelled out explicitly in the paragraph
prior to that. Also, that's how VB optional arguments work today (no
CLR/JIT magic), and I'd expect C# to do the same.
 
Back
Top