The Discussion

My question is about optional parameters in C#, or there lack of. VB.NET & CLR has support for them, but not C#. I have been hoping that C# 2.0 (Whidbey) will include support for optional parameters, but it seems that it will not.

What is the reasoning for not including optional parameters (aka default parameters) support with C#?

I think I've seen the reasoning for this from other languages (Java I believe). THe reason I recall is that you can handle optional parameters with method overloading and this also alleviates some ambiguity problems as well.

I've found that using overloading in C# is a lot easier and cleaner than using optional params in VB.
That said, the lack of optional params in C# becomes a REAL issue when automating any Office apps via Interop, where masses of optional params are very common.

Come to think of it, COM Interop on Office applications is so nasty I tend to stay far away at the best of times.

Strangely enough, in VB.NET you can use optional parameters OR overloading methods. I guess that's to let you use your preferred method, but personally I find it confusing (I prefer overloading too, by the way).

Once I read about an exprimental feature in Java that enables code that CATCHES an exception to be able to tell the original code that has THROWN the exception to continue to execute.

This would be useful if the catcher can handle and fix/resolve the cause of the exception and then "reverse throw" the exception back where it was thrown and continue as if the exception never had happened.

You are not wrong. In Java you can define which exceptions a method will throw by using the throws keyword. Consumers will know ahead of time which exceptions to catch. Anders explains the shortcomings of this pattern in the article I mentioned above.

You seem to be interested in exceptions. This is good

What do you think of the exception model currently in place in the Framework?

So these "checked exceptions" and your decision to avoid them is a good thing, I guess. But this would not make my original suggestion unusable, if I'm understanding correctly...

I do like exceptions, correct So in general I do like the exception model in the Framework very much.

In detail, I have problems to get the call stack information of the original thrown exception when installing a global exception handler in a C# application by implementing an
UnhandledExceptionEventHandler and a ThreadExceptionEventHandler. Never been able to get this working correctly. Probably it is
my fault, but since you are already asking, the Framework could help me more on this issue to avoid the mistakes I'm now making

Similar things apply when centrally catching exceptions in ASP.NET applications. But I'm trying to advance and improve!

If "What features would you like to see the C# team add?" is really mean what it is saying then this is my wish list:
(I have implemented some of these in a library named
Foop which is an alpha version)

1 - Define new operators; i.e. an operator named &&&.
2 - Define Generic operators; currently we can just overload the existing operators and if the operands are going to be Generic, they can only be of type of one of the Type Parameters of the container class.
3 - The pipe operator (|) as in F#; which can be there if we have feature number 2.
4 - Tuples; I have implemented some tuple data structures; but without compiler support, it needs to be implemented for any number of them!
5 - Better type inference; For example for lambdas I wrote a static method 'infer' for that I be able to define Extension Methods on delegates or use them in Anonymous Types:
new
{
Target = "XPC 10",
Vel = ExSyntax.infer ((int a) =>
{
return a * 22.8;
})
};
or
ExSyntax.infer (() =>
{
return DateTime.Now.Second > 10;
}).do_while_true (() =>
{
Console.WriteLine ("Updating Report...");
});
6 - Anonymous Types everywhere; which in fact is "good Type Inference" every where. I think as the members of Anonymous Types are the static members of the container class; so we can apply synchronization
and security facilities easily (I know you are the best and you are doing your best; so the "I think" part is just about the point of view from where that I am).
7 - Dynamic proxies; we can emit runtime types and cache them: declaring a new class that implements the target interface and has members of another type which is going to be have the interface (ducked!).
8 - Generic Generic Types; So I can define a typed linked list like this:
TyLList<A> {
public A Value;
public TyLList<?> Next;}
9 - Named parameter calling for functions; for void F(int a, string b) calling it like F(b = "OK", a = 10)
10 - Default values for parameters
11 - Calling function with an Anonymous Type with members which are named after function arguments:
For void F(int a, string b) calling F like F(new { b="OK", a=100});
(We already have 9, 10 and 11 for attributes!)
12 - Metaprogramming; (not IL weaving) which already have proof of concept projects like F# (Active Patterns and Typed Quoting ...)
13 - An even very simple form of syntax extending; with 12 we will have enough of this
14 - A #light syntax for C#; as we have in F#, which can be some form of indentation-based code layout (like in F#) with possibility yet to enclose code blocks in {}s.
15 - Tagging types; which will provides us Class Cases, I have implemented for example Either<A,B>, some people implement this by declaring additional types like Left<A> and Right<B>; that is wrong! GADT are distingushed from the way that the object is constructed
and the cases of the class in fact are different constructors which tag the object with different tags.
16 - 'this' refers to the current object; If there be somthing like this_type it is hand full (GetType is a runtime thing but this_type i.e. can be passed to Generics)
17 - Passing lambdas to attributes as parameter
18 - Defining Execution Contracts; like 'Ensure' and 'Requies' and with 14, even a new step in compiling a method or something.
19 - Capturing the values in the current execution context as a Name-Value dictionary; we have already the clousures and with 6, this would be very easy (this will provide us continuations).
20 - An attribute like [AloneExecutionPath] for methods; which grants that the methos just have access to it's parameters, and have not access to any public or internal thing in any assembly written by user (we can use .NET class library(is this good?) and
to the Anonymous Types defined inside the function and we can pass objects of those types)
22 - Curry is necessary;
21 - OK! OK! ...
I was just looking into my codes and comming back here and write things! I close Visual Studio for now!
Maybe this is another language! Yet I do not think so!

I have been playing around with the wonderfull new extension methods, templates etc.
You can do some great things with the new IEumerator<T> list constructs.
One of the things i really like about these is that you can apply them consistently accross a number of different types.

It seemed logical to do the same type of thing with trees however here-in lies a problem there is no consistantly used interfce such as IEnumerator upon which to base such extensions.
You can of course create the same code multiple times each one for a different type, but this seems really messy and inefficient.

What would be usefull would to provide allow extension interface implementations - a bit like a multiple inheritance extension.

// The above is ok - but we need to be specific about what class we are adding the inteface extension to.
// Also it would be nice to simplify the syntax a bit. So we we might re-write this something like:

// OK looks nice but how will this work in practice.
// The complier will compile the TreebaseExtn methods as before.
// So for it to work the above functions actually need to be passed a class that implements ITreeBase<T>
// To achive this the compiler simply creates an instance class of each of the extension classes (TreeNode,TreeView or XPathNavigator).
// These class are simply container classes each one has exactly just one field "this" which refers to an instance of the object we are extending.
// So for the first example it in effect complies as:

why not simply allow the scope to be implied by the enclosing braces?{
var x = new myglocal();
local var a = new c() ;
local var b = new d();
}

Also how about a thread-safe null-checking dot operator .? to supplement the
?? operator.
so var x= (a!=null)?a.fn():null
can be shortend tovar x = a.?fn();For value-types the return value could be up-converted to a nullbable type as required.int v = a?.MyIntFn() ?? mydefaultValue;
Invoking events/delegates could also be supported as folows myevent.?(sended,args);Removing one of the often -discussed current problems of how to achive this safely.