Add generic attributes proposal#4936
Conversation
|
Would a generic attribute parameter be allowed to be a type argument, so long as it was instantiated with a constant? E.g. public class Attr<T> : Attribute
{
public Attr(T t){}
}
[Attr<string>("hello world")] |
|
Yes, I expect that scenario to work. I'll try and make sure the feature branch has a test for it :) |
|
|
||
| > A type parameter cannot be used anywhere within an attribute. | ||
|
|
||
| This means that when a generic attribute is used, its construction needs to be fully "closed", i.e. not containing any type parameters, which means the following is still disallowed: |
There was a problem hiding this comment.
Is "closed" the correct term? "Opened" for generic types could refer to Type<>. I didn't think that Type<T> would be considered "open".
There was a problem hiding this comment.
I think so: https://github.com/dotnet/csharplang/blob/main/spec/types.md#open-and-closed-types
I think Type<> is an unbound generic type while Type<T> is an open generic type.
jcouv
left a comment
There was a problem hiding this comment.
Done with review pass (iteration 1)
|
|
||
| One important note is that the following section of the spec is *unaffected* when referencing the point of usage of an attribute, i.e. within an attribute list: https://github.com/dotnet/csharplang/blob/main/spec/types.md#type-parameters | ||
|
|
||
| > A type parameter cannot be used anywhere within an attribute. |
There was a problem hiding this comment.
Something about this line had me confused for a bit (as well as once before ~a year ago?), so I'm wondering if the spec needs to be rephrased to emphasize it refers to the attribute placement and not its definition.
There was a problem hiding this comment.
It does seem like it would be a little more clear to adjust the terminology to make attribute usages more distinct from their definitions.
|
Today |
Related to #124