WinRT reason for disallowing custom generic types or interfaces

Question

After reading about WinRT a bit here and from Build decks, can someone shed light on the specific rationale that lead them to disallow us from passing our own IFoo<T>, yet they do it for their own sanctioned generic interface types?

WinRT must have a mechanism for describing, resolving and passing generic arguments, or some fancy facading around this for their own use.

I can't imagine "flattening" some of my C# class utility libraries in non-generic fashion, which I mainly want to use from C++ and not so much from JS.

I want first-class Intellisense and API support just as much as you do for your own MS types.

So ... why can't we use said mechanism too? Is this likely to be relaxed and allowed later or is this a permanent restriction? Or is this due to the language projection layers themselves custom-handling specific generic types without some WinRT-centralized meta-handling common to any generic type?

Thanks.

Answer 1

Under the covers, the types which are projected as IXxx are implemented by what are called "parameterized interfaces" or "pinterfaces". Each language projection knows how to express the built-in parameterized interfaces in a natural and familiar fashion - for example, the IMap parameterized interface is projected by the CLR as IDictionary.

The language projections (especially JS) don't know what to do with custom parameterized interfaces, so they're not allowed.

There's no way of knowing if this restriction will be relaxed in the future, because there is no way of knowing what features will be added to Windows in the future.

Answer 2

Also for building component there are 2 advantages

• extension by composition is a better model for components ( remember you can still use interfaces for testing ( eg a C# lib) they just cant be exposes as WinRT exportable components

• No polymorphic calls across the COM call boundary since cant be inlined performance will be poor

I'm not sure JS would have limited this since JS cant create objects anyway only consume they could have added another JS limitation - not framework interfaces are supported..