Multi-constraint Generic Function Calls Actually Work?

In vb.net, it is possible to design a function which can operate on generic parameters which meet multiple constraints. For example, it is possible to have a function accept as a parameter a class which inherits from Control and implements IList. This function could use "Control" or "IList" methods on such an object, and also pass the object to anything that expected a Control or an IList [note that this particular combination was chosen to facilitate a brief example, not to be a particularly useful combination].

[Code]...

This approach provides compile-time type-safety; there's no need for a cast that could fail at runtime. An alternative approach would be to pass the argument as either a Control or an IList, and have the function cast to the other. That would, however, fail at runtime if the object that was passed didn't in fact meet both constraints.

Under what circumstances is it good to use a generic function like the above, in what cases would it be better to have objects which are going to meet both constraints have a new interface like IListableControl(Of T) which would include a TheControl property that would return itself (cast as a control), and in what cases would it be better to have a generic ISelf(of T) interface, any implementor of which would be expected to provide a "Self" property that would return itself as a T?

Using multi-constrained generics, it's possible to do a lot of things without requiring any run-time typecasts, but I don't know what the performance costs are likely to be. I tried writing a short program to generate 65,536 different generic types at run-time, e.g. Foo(of Bar(Of Foo(Of Foo(Of Bar(Of Foo(...(Of Blah)) and it got pretty slow, so I can tell that the time required to handle generics isn't fixed, but I don't know what factors affect it.