[Proposal] Allow generic attributes

[ashmind]

Problem

For some attributes (e.g. TypeConverterAttribute) that are used to reference types, the current usage looks like this:

[TypeConverter(typeof(X))]

This has two disadvantages:

1. You can't guarantee that the type matches the requirements of the attribute -- e.g. has an empty constructor or inherits TypeConverter.
2. The syntax is a bit verbose.

Suggestion

I suggest that the generic attributes should be supported, including any generic constraints.
Usage example:

[TypeConverter<X>]

Pros

1. Support for type constraints in type-referencing attributes
2. Shorter syntax
3. As far as I know, generic attributes are already supported in IL

Cons

The set of attributes that benefit from this might not be that large.

Updates

Removed pro 4 as it wasn't a pro.

[gafter]

3 and 4 are not pros, nor are they cons. 2 is marginal. 1 is the only justification that makes enough sense to consider it as a language feature. Do you have any use cases?

[ashmind]

To me 3 is important -- I don't see a reason why CS0698 exists in the first place, and removal of special cases should make language easier to learn and understand (especially since actual implementation can be done outside of the Roslyn team now).

I agree on 2 and 4.

Example attributes that could benefit from this (e.g. by defining a generic attribute subclass for old cases, and by defining the attribute as generic in new cases):

1. TypeConverterAttribute (new(), TypeConverter)
2. TypeDescriptionProviderAttribute (new(), TypeDescriptionProvider)
3. SettingsProviderAttribute (new(), SettingsProvider)
4. DesignerAttribute (new(), IDesigner, TDesigner: TDesignerBase)
5. InstallerTypeAttribute (new, IDesigner)
6. Newtonsoft.Json.JsonConverterAttribute (new(), JsonConverter)
   7... (Basically any *Provider/*Converter attribute I could find)

In fact ReSharper provides a special BaseTypeRequired annotation just for these cases -- allowing developer to specify the expectation.

[sharwell]

Ignore my previous comment (now deleted). The generic type arguments for a generic attribute type can be encoded in the MemberRef metadata table, by representing the "Class" field as a TypeSpec.

[Przemyslaw-W]

Glad I'm not the only one. https://roslyn.codeplex.com/discussions/542178

2015-03-02 0:29 GMT+01:00 Sam Harwell notifications@github.com:

Ignore my previous comment (now deleted). The generic type arguments for a
generic attribute type can be encoded in the MemberRef metadata table, by
representing the "Class" field as a TypeSpec.

—
Reply to this email directly or view it on GitHub
#953 (comment).

[mikedn]

(e.g. by defining a generic attribute subclass for old cases, and by defining the attribute as generic in new cases):

Problem is, the main advantage of this proposal is the support for generic constraints but the constraints can be easily circumvented by using the base attribute. You'd need to obsolete the TypeConverter's Type constructor to convince people to use the generic TypeConverter attribute and that's unlikely to happen. Besides, for some of these attributes (DesignerAttribute especially) it's more common to specify the type name rather than the type.

There's also the question of performance, do you really want to instantiate tens or maybe even hundreds of such generic attribute type just to get those generic constraints?

[sharwell]

Problem is, the main advantage of this proposal is the support for generic constraints but the constraints can be easily circumvented by using the base attribute.

A long discussion on a closely related scenario with the opposite conclusion is in dotnet/corefx#271.

[GeirGrusom]

Problem is, the main advantage of this proposal is the support for generic constraints but the constraints can be easily circumvented by using the base attribute.

How is that an issue that concerns the C# compiler? How is it an issue at all? Changing existing usage of attributes is not worthwhile, and the old attributes will continue to work, so why stop anyone?

You'd need to obsolete the TypeConverter's Type constructor to convince people to use the generic TypeConverter attribute and that's unlikely to happen

Why? It literally has no benefit to anyone to obsolete the old attributes. It would be counter-productive.

Besides, for some of these attributes (DesignerAttribute especially) it's more common to specify the type name rather than the type.

How does that concern generic attributes?

There's also the question of performance, do you really want to instantiate tens or maybe even hundreds of such generic attribute type just to get those generic constraints?

Why is that the compiler's problem?

[mikedn]

Why is that the compiler's problem?

Who says it the compiler's problem? This is a language feature, not some obscure compiler implementation detail that isn't part of the language specification. And as with all language features it's worth considering the pros and cons.

How does that concern generic attributes?

Use cases have been requested to support this language feature. Uses cases have been provided and I pointed out that some of these uses cases are not representative.

Why? It literally has no benefit to anyone to obsolete the old attributes. It would be counter-productive.

Yes, it would be counter productive to obsolete the old attributes and that's one of the reasons I already said that it won't happen. The side effect of not being able to do that is that the main selling point of this language feature (ability to use type constraints) is not very valuable for the presented use cases. For example, the consumer of TypeConverterAttribute still needs to deal with the fact that the specified type might not be a type converter after all.

How is that an issue that concerns the C# compiler? How is it an issue at all? Changing existing usage of attributes is not worthwhile, and the old attributes will continue to work, so why stop anyone?

Again, this is not about the C# compiler but about the C# language. A language would do well not to add features on the basis that "it is possible so why not?". A language feature should be useful, useful enough to pay for its cons.

[ashmind]

The side effect of not being able to do that is that the main selling point of this language feature (ability to use type constraints) is not very valuable for the presented use cases.

I don't really see it as a feature that would directly benefit those attributes (though even subclasses would make those somewhat nicer to use). The thing is -- there are a lot of APIs created for .NET all the time, including MS obsoleting some APIs, creating new APIs, etc.

Based on the attributes we see now, it's not hard to see that those APIs are likely to use similar approaches -- and in those cases there will be no legacy parts to care about.

A language feature should be useful, useful enough to pay for its cons.

I am still not fully clear on how it works with new, open-sourced Roslyn. I think I read somewhere that the team had -100 points as a starting cost of any feature.

However, what if the feature has no obvious cons and is implemented completely through contributors? Of course there would be still some work required to review it, but is it -100 anymore?

[gafter]

The -100 points don't come primarily from implementation effort. It comes from increased complexity of the language.