You use 'and'

1
2
3
4

 

let foo (bar : 'a when 'a :> IEnumerable and 'a :> IDisposable) = 1

I notice Intellisense in Visual Studio is showing only one constraint - this is a bug.

Subtyping constraints are excellent for modelling traits that apply to values, rather than to a type. For example, "IEnumerable" applies to values, but "IArithmetic<T>" applies to a type. Put another way they are only really useful for modelling traits whose members are all of the form:

1

   member trait : T -> ...

such as

1
2

   member Dispose : T -> unit
   member GetEnumerator : T -> IEnumerator

etc. Because of this constraints are strictly more limited than type classes - you can tell that partly by the fact that no dictionary arguments get implicitly inserted as in Haskell type classes - instead constraints are implemented by reference to the vtables attached to values.

C# extension methods do not include new interface subscriptions, and are not even discoverable via reflection. They are thus of no real use in this setting, though like many C# 3.0 features have a tantilizing feel because they give a hint at the form of extensibility that type classes give.

It seems to me that any extensions to an interoperable CLR language in this part of the design space effectively requires the use of dictionary passing (which for subtype constraints would break how implementations of constraints are transmitted across interoperability boundaries) OR a global table listing constraint interfaces and interface subscriptions (which breaks lexical scoping and doesn't fit well with dynamic loading). So the set of instances of subtyping constraints will not be extensible in F# (i.e. you won't be able to declare new interface subscriptions for a type after-the-fact).

That said, I often go close to designing and implementing a type class mechanism as an extensible means to pass parameters around implictly through F# code (though I have a strong preference to allow people to override the dictionaries).

Don