從一開始， Attribute 就是.NET 的一部分。因此，它們在引入泛型之前就已經被創建好，這意味著如果要引用屬性中的類型，必須暴露一個 Type 參數或屬性。例如：

[TypeConverter(typeof(X))]

這種模式存在一些限制。在上面的示例中，X 必須有一個無參數的構造函數，并繼承 TypeConverter。編譯器不會強制這些，所以開發人員只能在運行時發現錯誤。

相反，如果我們使用泛型類型參數，那么就可以在編譯器強制執行這些規則，而且語法會稍微清晰一些。

[TypeConverter<X>]

理論上，“Allow Generic Attributes”提案是一個非常簡單的變更。CLR 已經支持這個概念，問題是如何在.NET 語言中使用它。但有時候理論和現實是兩條平行線，而且即使 CLR 可以支持，并不代表就一定會支持。Jan Kotas 解釋說：

我認為這個問題的本質與局部引用和 return 類似。局部引用和 return 不受任何 API 的限制，理論上它們在現有的運行時、工具和庫上都能正常運行。但在實際當中，它們可能不能正常運行，因為它們暴露了預先存在的錯誤和限制，可能是因為它們的處理路徑從未被執行過，或者它們明顯不在預期之內。與引用 return 相關的錯誤和問題剛剛開始出現，因為人們開始使用這項功能，并發現了一些不奏效的地方。我認為這在預期之內。我們應該承認這些事實，并且不會采取之前我們撤回默認值類型構造函數功能那樣的行動。

這個功能非常類似。ECMA 并沒有針對禁止使用泛型 Attribute 的內容，在理論上應該可以正常運行，但實際上卻沒有。如果要正常運行，必須更新整個系統中的很多部件：

存在多個運行時（Mono、CoreRT、整個框架）；

IL 的一些工具也可能會受到影響（編譯器、基于 Cecil 或基于 CCI2 的工具）；

可能需要用于訪問泛型 Attribute 的 API（例如，現有的反射 API 不允許你訪問泛型 Attribute——你必須進行枚舉）。

該提案的一個限制是在編譯時必須“關閉”Attribute 功能。下面是提案中提供的一個啟用泛型 Attribute 的例子。

[SomeAttribute<T>]

public void DoSomething<T>(T input) { }

因為 T 不是在編譯時定義的，因此反射機制就不知道這個表達式會返回什么。

typeof(GenericClass<>).GetMethod("DoSomething").GetCustomAttributes()

狀態

目前，泛型 Attribute 功能列在C# 8 路線圖中，狀態為“進行中”。

查看英文原文：https://www.infoq.com/news/2019/01/Generic-Attributes

總結

以上是生活随笔為你收集整理的C# 8 新提案让泛型 Attribute 成为现实的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。