Short list of non-obvious things determined from the C# 2.0 draft

A short list of things I could determine from the C# 2.0 draft which was released yesterday which are not a topic of much discussions but are good to know. I've added page numbers to the items, so you can go back to the C# 2.0 draft yourself and look them up (page numbers are the actual page numbers on the page). I've skipped the features: Generics, Anonymous methods, Iterators and Partial types, because these are the obvious items discussed in the draft :)

  • No support for multiple similar overloads with different returnvalues (Page 18)
    Sometimes you want to specify different overloads which have the same method declaration (method signature) but differ only in return type. There was speculation that support for this would be added to C# (Eiffel has it). However on Page 18, an example shows us that it will not be added: 
    class G1<U>
{
	long F1(U u);	// Invalid overload, G<int> would have two
	int F1(int i);    	// members with the same signature
	// ...
}
  • Support for Nullable types (Page 27)
    A very nice thing that will be added to .NET is the support for Nullable types. In .NET 1.1, you can't use an int variable in a situation where you want it to be null as well. You could use SqlTypes.* but these are not serializable. LuKa has programmed Nullable types for .NET, but that requires that someone using your code includes a reference to that library. A native FCL version of Nullable types is a welcome addition.
  • Type inference reduces typing, increases complexity for the reader (Page 30)
    Type inference is the mechanism the compiler will use to determine which constructed type to use by looking at the type of the parameters passed in. Example:
    class Util
{
	static Random rand = new Random();
	static public T Choose<T>(T first, T second) {
		return (rand.Next(2) == 0)? first: second;
	}
}
    will result in different types in the method when called using different types: 
    int i = Util.Choose(5, 213);		// Calls Choose<int>
string s = Util.Choose("foo", "bar");		// Calls Choose<string>
    While this saves the developer some typing, it is less readable code, IMHO, because when used with parameters, it is harder to determine by simply reading the code which constructed type the method will have.
  • Properties, events, indexers or operators may not be generic (Page 32)
    This may be a big item for some people and I fail to see why indexers and properties aren't among the elements which can be made generic. Especially properties and Indexers are extremely important for generic collections. But perhaps I'm mistaken and I didn't read the draft correctly.
  • Partial types must be compiled together (Page 70)
    I quote: "All parts of a partial type must be compiled together such that the parts can be merged at compile-time. Partial types specifically do not allow already compiled types to be extended.". It is understandable from a compiler's POV, it can be confusing perhaps when starting with Partial Types. Partial Types are extremely useful for code generators, and I can't wait to implement them :) The only fear I have is that Partial Types will not be part of VB.NET, so code generators which target multiple .NET languages are not helped by it in some cases. However I read somewhere that ASP.NET 2.0 uses partial types so VB.NET should support them as well.

I haven't looked deeply into iterators and anonymous methods yet, plus I'm sure I've overlooked some non-obvious gems so when you have any extra info, post them in the comments :)

4 Comments

  • Partial types are part of VB.NET also, so don't worry about that one.

  • What I didn't find (but hoped for) are different access levels for properties.



    I.e. A public property set, but protected property get.



    Or didn't I search to spec hard enough?



    I sent a mail to &quot;Ask a language designer&quot; about this today... let's see what the response is.



    Roland

  • In regard to properties:

    &quot;Properties, events, indexers, and operators may not themselves have type parameters (although they can occur in generic classes, and use the type parameters from an enclosing class).&quot;



    By my reading, that means that:



    public class Generic&lt;T&gt;

    {

    T Property{get{...}}

    }

    is correct while



    public class Generic

    {

    T Property&lt;T&gt;{get{...}}

    }

    is not. Its not really a surprise considering that collection types would be specified in the class and that there is no mention of paramaterized properties(which really aren't needed, IMHO).



    Another thing I like is Method group conversions(page 14, section 19.21.1) which basically allows the compiler to infer delegate types instead of requring the new DelegateName() syntax. So code like

    btn1.Click += btn1_Click;

    works instead of requireing

    btn1.Click += new EventHandler(btn1_Click);

    for example. It is simply easier and I suspect will be easier for new users and non-IDE users(as it stands, I just hit tab twice to build an event handler, so its not going to save me much typing).



    I am also pleased that iterators aren't strictly restricted to GetEnumerator\foreach keyword like was mentioned early on, but can be defined as any method that returns IEnumerable\IEnumerator(or the generic counterparts), allowing for more creative uses of the feature.



    One last gotcha, although its pretty obvious, the spec mentions that using aliases in partial types only apply to the scope they are defined in, meaning that in ClassPt1.cs and ClassPt2.cs the same type alias could refer to different types. Its not a feature so much as a potential problem if not carefully used(I don't like aliases anyway, hopefully this won't cause any extended confusion).



    Beyond that, I wonder if this is a complete draft of what they are adding, or if it is simply a teaser spec for the 4 big features we are all expecting, while leaving out maybe some smaller things, like seperate property access levels(which no one knows if it will be there or not, form what I've read, the camp is pretty divided in MS). I wouldn't be surprised if there are other smaller enhancements that won't be announced until the PDC, or maybe not even noticed until someone reads the final spec, but I could also be wrong.



    My favorite oversight so far, however, is the spec doesn't deal with default constructor constraint usage too clearly(only place I saw discussion on the inclass syntax was in the first section, not the whole spec) and the lack of non-default constructor constraints.

  • To address Roland's post - you will be able to have a public get and a private set on properties in whidbey

Comments have been disabled for this content.