Recently I asked a question here about using F# extensions in C#. Brian quoted:
Per the language spec, section 10.7 "Type extensions":
Optional extension members are syntactic sugar for static members. Uses of optional extension members elaborate to calls to static members with encoded names where the object is passed as the first argument. The encoding of names is not specified in this release of F# and is not compatible with C# encodings of C# extension members.
I am wondering if there are any other interoperability issues in .NET that restricts the usage of some functionality to some languages but not others?
I expect there are lots of things, but mostly in corner cases if you're talking about the major managed languages (C#, VB, and soon F#). Other cases where F# currently interacts poorly with C# is when there method overloads that take both Action and Func (the C# overload resolution works differently than F#, so F# calls to such an API may be more verbose); 'params' argument arrays (especially when trying to tak advantage of 'array covariance', which is a feature of C# but not F#); there are some issues regarding subclassing or implementing interfaces, combined with accessibility (e.g. public versus internal), where sometimes you cannot derive an F# class from a C# one...
Many of these issues are simply either 'bugs' in the F# CTP compiler or 'design issues' with the F# language spec that may be changed before the final release of F#.
I don't know the dusty corners of the CLR well enough, but I bet that there are places where C# and VB fails to mesh. And there are features of the CLR that none of the major languages use, so I expect there's ways to create valid IL that may cause problems with some interop.
Overall I think all this stuff is minor, and in the case of F#, a bit of it will be 'fixed' before the final release. But I will be curious to see what other things people call out, as it could be useful feedback for the managed language teams at MS.