Rational for not supporting optional arguments

[Nick Hounsome]

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them, I
would not expect them to be omitted without a good reason.

[rmacias]

Optional parameters was not written into the Common Language Specification,
so therefore not all .NET languages are able to understand them. I believe
C# is meant to be CLS compliant, and so no support for optional parameters.

"Nick Hounsome" wrote:

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them, I
would not expect them to be omitted without a good reason.

[Nick Hounsome]

"rmacias" <rm*****@newsgroup.nospam> wrote in message
news:7F**********************************@microsof t.com...

Optional parameters was not written into the Common Language
Specification,
so therefore not all .NET languages are able to understand them. I
believe
C# is meant to be CLS compliant, and so no support for optional
parameters.
C# is full of non-CLS compliant features.

Optional parameters can even be made "CLS compliant" if it is explicitly
stated that the compiler will generate the equivalent overloads - it's
considerably less magical than generating "magic" methods for property and
event access.
"Nick Hounsome" wrote:

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them, I
would not expect them to be omitted without a good reason.

[Jon Skeet [C# MVP]]

Nick Hounsome wrote:

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them, I
would not expect them to be omitted without a good reason.

Mostly versioning, I believe. Because the default values end up baked
into the *calling* assembly, if a new version of the assembly comes out
with different default values, you end up with problems.

Jon

[Michael Nemtsev]

They say it's are really most common reason

--
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do
not
cease to be insipid." (c) Friedrich Nietzsche

[Michael Nemtsev]

They say it's really most common reason

--
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche

[Lasse Vågsæther Karlsen]

> Nick Hounsome wrote:

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them,
I would not expect them to be omitted without a good reason.

Mostly versioning, I believe. Because the default values end up baked
into the *calling* assembly, if a new version of the assembly comes
out with different default values, you end up with problems.

Jon

There's three ways to implement this (that I know of):

- real optional parameters, make the jit'er fixup this at jit time, the code
would contain a call to the method with the list of parameters that the calling
code has, this will be matched to a method at runtime
- copy default values to calling assembly, match at compile time
- make overloads for all combinations and make calling code call the right
one, match at compile time

The problems with these are (in the same order):

- versioning, if a new assembly comes out with different methods/overloads/default
values, the calling code would match a different method. Could be benign,
could be harmful.
- versioning, as you mention, if a new assembly comes out with new values,
those are already baked into the calling assembly
- ?

The last one I don't have a problem with. I'm sure there are some, but isn't
this the route VB.NET took?

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2

[Nick Hounsome]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

Nick Hounsome wrote:

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them, I
would not expect them to be omitted without a good reason.

Mostly versioning, I believe. Because the default values end up baked
into the *calling* assembly, if a new version of the assembly comes out
with different default values, you end up with problems.

Not a problem if you implement it as a set of overloaded ctors - the
optional values are "baked" in the class not the caller.

[Nick Hounsome]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:a0*************************@news.microsoft.co m...

Nick Hounsome wrote:

Can anyone tell me what the rational is for not supporting optional
arguments.

It is obviously a trivial thing to implement and, since C++ has them,
I would not expect them to be omitted without a good reason.

Mostly versioning, I believe. Because the default values end up baked
into the *calling* assembly, if a new version of the assembly comes
out with different default values, you end up with problems.

Jon

There's three ways to implement this (that I know of):

- real optional parameters, make the jit'er fixup this at jit time, the
code would contain a call to the method with the list of parameters that
the calling code has, this will be matched to a method at runtime
- copy default values to calling assembly, match at compile time
- make overloads for all combinations and make calling code call the right
one, match at compile time

The problems with these are (in the same order):

- versioning, if a new assembly comes out with different
methods/overloads/default values, the calling code would match a different
method. Could be benign, could be harmful.
- versioning, as you mention, if a new assembly comes out with new values,
those are already baked into the calling assembly
- ?

The last one I don't have a problem with. I'm sure there are some, but
isn't this the route VB.NET took?

public X(optional int a = 7,optional string b = "hello")
{
//stuff
}

becomes effectively

public X()
{
int a = 7;
// stuff
}

public X(int a)
{
string b = "hello";
// stuff
}

public X(int a,string b)
{
// stuff
}

referencing code would ALWAYS see it as an overload and there is no
versioning problem.

The code generated for each ctor is lightly different because of the
different ways of accessing "a" and "b" but this is trivial.

It is really no more magic than "params" which don't really exist as such in
the generated code either.

[Lasse Vågsæther Karlsen]

> "Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message

news:a0*************************@news.microsoft.co m...

Nick Hounsome wrote:

<snip> public X(optional int a = 7,optional string b = "hello")

Actually you would have:

public X(int a, string b)
{
// code
}

public X(int a) : this(a, "hello")
{
// nothing here
}

public X(string b) : this(7, b)
{
// nothing here
}

public X() : this(7, "hello")
{
// nothing here
}

And then in a different assembly you do this:

X x = new X(10);

this would equate to:

X x = new X(10, "hello");

Would this compile to:

1. X x = new X(10); // magic happens at jit-time
2. X x = new X(10, "hello"); // magic happens at compile time

With the first, it might work, basically you're saying that you only want
to call the constructor providing an integer.

With the second, if the original assembly now adds a third optional parameter,
you're back to square one.

The above syntax doesn't cater for one thing though, which is multiple parameters
of the same type:

public Y(optional string a = "a", optional string b = "b")

this would lead to the VB syntax, with empty parameter specifications:

Y y = new Y(, "hello")

Not sure I like this anyway.

What could be a solution would be for the "default" keyword to apply to parameters
as well, and thus the above could be:

Y y = new Y(default, "hello")

or:

Y y = new Y(default(a), "hello")

In any case, I doubt optional arguments is headed for C#.

--
Lasse Vågsæther Karlsen
http://usinglvkblog.blogspot.com/
mailto:la***@vkarlsen.no
PGP KeyID: 0x2A42A1C2

[Amir_Hasan]

even in C++ it is best we avoid multiple default parameters as it leads
to this kind of confusion for the caller. To address the issue above
they introduced in C++ the idea that the defaults are based "from the
end" of the parameter list.

I think the main idea behind not having default parameters is that it
causes all sorts of issues which are common in C++ Such as Binding of
virtual methods. (have a look at this issue
http://www.thescripts.com/forum/thread60184.html)

What about Delegates? Can a delegate signature be given a default
parameter? If so How is that going to work? What if the invocation list
has attached a method with a different default value for the default
parameter and the delegate is being invoked using the delegate
defaults. Should that method be called with the delegate default or be
called with the methods defaults?

Basically default parameters causes all sorts of cans of worms to be
opened up. Most people can get by without them them by using the
technique above (stub method which calls the explicit method). Coming
from a C++ background, It would be nice but it is something I can live
without.

Amir

[Nick Hounsome]

"Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:a0*************************@news.microsoft.co m...

"Lasse Vågsæther Karlsen" <la***@vkarlsen.no> wrote in message
news:a0*************************@news.microsoft.co m...

Nick Hounsome wrote:

<snip>

public X(optional int a = 7,optional string b = "hello")

Actually you would have:

public X(int a, string b)
{
// code
}

public X(int a) : this(a, "hello")
{
// nothing here
}

public X(string b) : this(7, b)
{
// nothing here
}

public X() : this(7, "hello")
{
// nothing here
}

You are right about the this() implementation but I was thinking of C++
rules whereby you can only omit trailing parameters so X(string) is not
possible.

And then in a different assembly you do this:

X x = new X(10);

this would equate to:

X x = new X(10, "hello");
It depends what you mean by "equate to".
It would call the ctor X(int) as you show above. It would indeed have the
same functionality.

Would this compile to:

1. X x = new X(10); // magic happens at jit-time
2. X x = new X(10, "hello"); // magic happens at compile time
There is no magic in either case - the compiler would just call the
appropriate overloaded ctor.

This is entirely different to the way that C++ works:
C++ causes the calling code to add parameters to a call to a single method.

optional by overloading works by calling the overloaded method that matches
the parameters.

With the first, it might work, basically you're saying that you only want
to call the constructor providing an integer.

With the second, if the original assembly now adds a third optional
parameter, you're back to square one.
No. You just have an extra overload of the ctor.

The above syntax doesn't cater for one thing though, which is multiple
parameters of the same type:

public Y(optional string a = "a", optional string b = "b")

this would lead to the VB syntax, with empty parameter specifications:

Y y = new Y(, "hello")

Not sure I like this anyway.
No - C++ rules - only trailing parameters may be omitted.
You would have:
Y(),Y(string a),Y(string a,stringb)

What could be a solution would be for the "default" keyword to apply to
parameters as well, and thus the above could be:

Y y = new Y(default, "hello")

or:

Y y = new Y(default(a), "hello")

In any case, I doubt optional arguments is headed for C#.

You are probably right but I'm still waiting for a good reason why not.

[Nick Hounsome]

"Amir_Hasan" <ah****@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

even in C++ it is best we avoid multiple default parameters as it leads
to this kind of confusion for the caller. To address the issue above
they introduced in C++ the idea that the defaults are based "from the
end" of the parameter list.
That was what I had in mind too. In fact it didn't occur to me that anyone
would think otherwise since C# has a roughly C++ style syntax.
I think the main idea behind not having default parameters is that it
causes all sorts of issues which are common in C++ Such as Binding of
virtual methods. (have a look at this issue
http://www.thescripts.com/forum/thread60184.html)
This example would not be allowed.
C# is already very hot on dissalowing possible ambiguities and I would make
it a compile time error.

What about Delegates? Can a delegate signature be given a default
parameter? If so How is that going to work? What if the invocation list
has attached a method with a different default value for the default
parameter and the delegate is being invoked using the delegate
defaults. Should that method be called with the delegate default or be
called with the methods defaults?
Using overloading to provide the defaults makes it impossible to have
delegates with defaults but then I can't see a use for them anyway.

Basically default parameters causes all sorts of cans of worms to be
opened up. Most people can get by without them them by using the
technique above (stub method which calls the explicit method). Coming
from a C++ background, It would be nice but it is something I can live
without.

You are thinking of implementing them as C++ does.
If you implement them using overloading then the problems go away.