在这里和Build甲板上阅读了一下WinRT之后，有人能够了解导致他们不允许我们通过我们自己的IFoo＆lt; T＆gt;的具体原理，但是他们是否为他们自己认可的通用接口类型做了什么？
WinRT必须有一种机制来描述，解析和传递泛型参数，或者有一些花哨的内容围绕它自己使用。
我无法想象以非泛型方式“扁平化”我的一些C＃类实用程序库，我主要想要使用C ++而不是JS。
我希望获得一流的Intellisense和API支持，就像您对自己的MS类型一样。
那么......为什么我们也不能使用这种机制呢？这可能是放宽并允许以后或这是一个永久限制？或者这是由于语言投影层本身是自定义处理特定的泛型类型而没有任何泛型类型通用的WinRT集中式元处理？
感谢。
答案 0 :(得分：7)
在幕后，作为IXxx投影的类型由所谓的“参数化接口”或“pinterfaces”实现。每种语言投影都知道如何以自然和熟悉的方式表达内置的参数化界面 - 例如，IMR参数化界面由CLR投影为IDictionary。
语言预测（尤其是JS）不知道如何处理自定义参数化接口，因此不允许使用它们。
无法知道将来是否会放宽此限制，因为无法知道将来会向Windows添加哪些功能。
答案 1 :(得分：1)
对于建筑构件也有两个优点
按组合扩展是组件的更好模型（记住你仍然可以使用接口进行测试（例如C＃lib），它们不能作为WinRT可导出组件公开
COM调用边界没有多态调用，因为内联性能不佳
我不确定JS会限制这个，因为JS无法创建对象，只是消耗它们可能添加了另一个JS限制 - 不支持框架接口..