Pingback from  Dew Drop - December 3, 2008 | Alvin Ashcraft's Morning Dew

I generally agree with you about typed exceptions, but I'm not sure how much more the C# team can do for generics aside from providing better support for variance.  C#'s strict type safety is one of its virtues and helps lead developers into the "pit of success", as Brad Abrams likes to say.  Generic constraints offer a bit more control, though they are more limited in C# than in some other languages (e.g. you cannot constrain to an Enum in C#, but you can in C++/CLI).  It seems to me that if you're looking for more flexibility, you should be actively trying to *avoid* constraints on your generic parameters.  That said, I'm curious to hear what changes you think should be made.  I'm hardly an authority on the subject, so perhaps you have some insights that I hadn't considered.

As for making all methods and properties virtual by default, I urge you to consider the performance ramifications.  All method and property accessor invocations would result in a vtable lookup by default.  While this may seem like an insignificant performance hit (and for individual method calls, you might be right), but it really adds up.  There's no doubt in my mind that the C# team made the right call here.

If some public method in a public class of yours has a generic constraint, and in there you instantiate some class with that type argument, how could you avoid by design of a statically typed language that you don't need the same or a stronger constraint on said class?

From my experience a design decision may have to be re-thought if the constraints are rippling through the system far too wide. If the constraints just "fall into place" it is rather satisfying. Admittedly, changing constraint decisions is quite painful.

@Jeremy: I agree completely that better type inference would be a welcome improvement.  Further, that type of improvement is preferable because it mostly affects  the compiler and does not significantly alter the language specification.

Aside from the performance issue regarding methods being virtual by default, there is the issue of versioning.  In a perfect world, developers would never forget to seal methods that should not be overridden and would not expose methods as virtual if altering the behavior could break the functionality of the class.  Unfortunately, that is a long shot from reality.  We can certainly agree to disagree, but I believe that having methods sealed by default results in more maintainable code, particularly when that code is written by junior developers.

The cruft that generic constraints bring to the table is something that bothers me almost every day but couldn't get so nicely expressed in a blog post like yours. Soooo true.

Unless you want your users experiencing bizarre errors are JIT time (or give up the ability to have generic class definitions in separate assemblies), there is really no way around generic constraints.

Cannot say that generic constraints have ever offended me to be honest.. so to me this is a bit confusing.

Could you give a complete sample of the sort of thing you want where type inference doesn't work today? I tried this code, which I thought at first was similar to what you want, and it inferred fine, so I must be missing something.

public static class Program

{

   static void Main(string[] args)

   {

       var x = new System.Collections.Generic.List<int>();

       var y = x.Map((i) => i.ToString()).Map((s) => System.Int32.Parse(s));

   }

   static System.Collections.Generic.IEnumerable<U> Map<T,U>(this System.Collections.Generic.IEnumerable<T> x, System.Func<T,U> f)

   {

       return new System.Collections.Generic.List<U>();

   }

}

Also annoying are the, um, constraints on constraints. Why can't I constrain to a type with a particular ctor signature? And don't get me started on operators...

Instead of "constraints on new", I think a much nicer pattern is to pass a delegate whose job it is to construct the thing. Here's some code which requires a constructor of signature (int,string):

   Sub f(Of T)(ByVal f As Func(Of Integer, String, T))

       Dim newlyConstructedObject = f(1, "hello")

   End Sub

   Sub Main()

       f(Function(i, s) String.Format("{0}:{1}", i, s))

   End Sub

This way is more flexible because accessibility of the delegate is as it was at the callsite of the generic function where it's supposed to be. Also it supports the object-initializer idiom.

I absolutely agree with Lucian. Constraining to a particular constructor signature, even if it is the default signature, is a perversion of OOP and the concept of constructors.

As for virtual-by-default, nothing would more quickly destroy the extensibility of frameworks (not just the BCL), and I am very glad that the .NET designers made the right decision here. If they hadn't I probably wouldn't even be using .NET today.

A new Code Contracts preview is now available on DevLabs. Code Contracts will be part of the base class...

A new Code Contracts preview is now available on DevLabs . Code Contracts will be part of the base class