属性は初期から.NETの一部であった。そういうものとして、ジェネリクスが導入される前に始まり、全く触れられることはなかった。属性内の型を参照する場合は、Typeパラメータまたはプロパティを公開しなければならない。例を次に示す。
[TypeConverter(typeof(X))]
このパターンにはいくつかの制限がある。上記の例では、Xはパラメータのないコンストラクタを持ち、TypeConverterから継承する必要がある。これはコンパイラによって強制することはできないので、開発者は実行時まで間違いに気付かれることはない。
代わりにジェネリック型パラメータを使用した場合は、コンパイラ時に規則を適用しながら制約を適用できる。そして構文は少しきれいになる。
[TypeConverter<X>]
理論的には、Allow Generic Attributes提案は非常に単純な変更である。CLRはすでにこの概念をサポートしている。それは.NET言語でそれを公開するだけのことである。しかし、理論と実践はしばしば一致せず、それは、CLRがサポートするということは、.NET言語での公開をサポートすることを意味するとは限らないためである。Jan Kotasは次の通り説明する。
私はこの問題の本質はrefローカルとrefリターンに類似していると考えています。refローカルとrefリターンはどのAPIによってもキー設定されていません。理論上は、既存のランタイム、ツール、ライブラリでうまく動作するはずです。実際には、既存のバグおよび制限が表面化したために、うまく動作しません。それらを処理するパスが実行されなかったり、またはそれらが明確に予期されたものでなかったためです。byrefリターンに関連するバグや問題は、人々がこの機能を使い始めて、うまく動かない場所を見つけることで、見え始めたばかりです。それは大丈夫ですし、予想通りのことです。私たちはそれを認めなければなりません、そして前にデフォルトのvaluetypeコンストラクタのためにしたように機能を後退させる反応をしないでください。
この機能はかなり類似しています。ECMAには、ジェネリック属性を禁止するものは何もなく、理論上は問題なく機能するはずです。実際にはそうではありません。システム全体を通して多くの部分を、それらがうまく機能するように更新する必要があります。
- あなたが言ったように心配するべきランタイムが複数あります（Mono、CoreRT、フルフレームワーク）
- IL上で動作するツールの中には、影響を受ける可能性があるものもあります（コンパイラ、CecilベースまたはCCI2ベースのツール）
- ジェネリック属性にアクセスするための新しいAPIが必要になるかもしれません（たとえば、既存のリフレクションAPIでは一般的な属性に効率的にアクセスできません（常に列挙する必要があります））
この提案の1つの制限は、コンパイル時に属性が「閉じている」必要があるということである。それが何を意味するのかを説明するために、ここに提案からのオープンジェネリックの例がある。
[SomeAttribute<T>]
public void DoSomething<T>(T input) { }
Tはコンパイル時には定義されていないため、リフレクションはこの式に対して何を返すべきかを知らない。
typeof(GenericClass<>).GetMethod("DoSomething").GetCustomAttributes()
ステータス
現在、Generic Attributes機能はC# 8ロードマップに「In Progress」ステータスとしてリストされている。