This project is read-only.

Attribute enhancements

Topics: C# Language Design
Sep 8, 2014 at 2:56 PM
Have there been any discussions around extending the abilities of attributes, such as allowing generic attributes, or anonymous objects as parameters/properties?
Sep 8, 2014 at 3:11 PM
Not that I'm aware of. This would probably also require CLR changes.
Sep 9, 2014 at 10:30 AM
I would vote for this if it was possible.
Sep 9, 2014 at 3:24 PM
With some IAttributeSerializer we can have it :)

Whe we write:
MyAttr : Attribute, IAttributeSerializer 
{
    MyAttr(){}
    MyAttr( SomeObj obj ){}

    Serialize( SerializationContext c ){}
    Deserialize( SerializationContext c ){}

    SomeObj _obj;
}

[MyAttr(new SomeObj( ... ))]
void     Foo (){...}
Compiler can use serialize for serializing specific attribute fields and then empty constructor and Deserialize to deserialize attribute in runtime
Sep 9, 2014 at 3:43 PM
This would probably also require CLR changes.
Well, you know, if you can store strings in metadata, it means, that you can store anything in metadata.
Sep 9, 2014 at 3:47 PM
Edited Sep 9, 2014 at 3:49 PM
+1 :)
Sep 9, 2014 at 11:29 PM
kekekeks wrote:
This would probably also require CLR changes.
Well, you know, if you can store strings in metadata, it means, that you can store anything in metadata.
Sure. So why don't we just store uncompiled C# code in metadata? No need to specify the IL then. Also, we could use strings to replace both integer and floating point arithmetic... sarcasm off
Sep 10, 2014 at 7:04 AM
Expandable wrote:
Sure. So why don't we just store uncompiled C# code in metadata? No need to specify the IL then.
Because CLR can store IL and no need to store C# code in metadata.
.
Also, we could use strings to replace both integer and floating point arithmetic...
If you want, you can, can not imagine why you are suffering when CRL can operate with floating point and integer arithmetic.

We there propose the ways to add important feature to C# without need to change CLR. Hope you understand now.
Sep 10, 2014 at 12:10 PM
Discussion about generic attributes (no answers): https://roslyn.codeplex.com/discussions/542178

5 year old question about generic attributes support in C# on Stack Overflow has more than twenty thousand views.
Sep 11, 2014 at 2:58 PM
Interesting, didn't realize that the runtime already supported generic attributes:
.custom instance void class [TestAttr]MyAttribute`1<int32>::.ctor(!0) = ( 01 00 7B 00 00 00 00 00 ) // [MyAttribute<int>(123)]
I guess the question here would be use-cases. It can replace the use of typeof() but what would the benefits be (other than not typing a few characters)?
Sep 11, 2014 at 4:02 PM
what would the benefits be
If multiple usage of an attribute is disallowed, generic one can be applied multiple times with different type arguments.
Sep 12, 2014 at 11:31 PM
I guess the question here would be use-cases. It can replace the use of typeof() but what would the benefits be (other than not typing a few characters)?
Type safety, e.g. if you have an IConverter class and a ConverterAttribute that marks stuff that needs to be converted with a type as a generic parameter, you can make sure the provided type inherits from IConverter at compile-time rather than doing runtime checks.
Sep 14, 2014 at 6:45 PM
Halo_Four wrote:
I guess the question here would be use-cases. It can replace the use of typeof() but what would the benefits be (other than not typing a few characters)?
The ability to specify arguments of the generic type(s).
Sep 14, 2014 at 6:48 PM
Expandable wrote:
kekekeks wrote:
This would probably also require CLR changes.
Well, you know, if you can store strings in metadata, it means, that you can store anything in metadata.
Sure. So why don't we just store uncompiled C# code in metadata? No need to specify the IL then. Also, we could use strings to replace both integer and floating point arithmetic... sarcasm off
There is no inherent advantage to doing that. Reductio ad absurdum works better when the original proposition is actually absurd.
Sep 15, 2014 at 12:26 PM
I only stopped fighting for new features in attributes years ago when someone on the team walked me through their view that attributes, and their current use in assembly metadata are a fundamental feature of .NET and redefining them requires some enormous rethinking of CLI and metadata itself and possibly deep breaks to standards.

"Putting interesting things in strings" seems the core of kekekes's point. I think that's a great idea, but not into the existing attributes because they heavily imply assembly metadata attributes. They almost always appear in the metadata, and they are so fabulously successful that I don't see a reason to change them.

There's also the issue of putting them anywhere and having them free-floating. This is also extremely fundamental to the definition of attributes.

Attributes are marker that carry information. If we create a new thing - I have called it [compiler communication] to avoid implying an implementation, but this thread has convinced me I'm wrong because I'm implying a usage with the word "compiler". If we think just of [communication] (bracketed), then there are many ways to do this and many targets.

I really, really want to see an implementation of this feature in the first release after C# 6. We've been hamstrung by this way too long.

What can constructively come out of this thread is an implementation and target free terminology, which will allow us to go to user voice and start requesting use cases from the full .NET population. I believe only with that use case can we (me at the top of the list, thank you all for expanding my thinking) go beyond our narrow thinking of what we (ME! but of course I know how people that work like me will benefit too) personally need to see a really great design and implementation. There are a hundred ways to use this feature that you and I have not thought of yet.

And once we get that, "string" will become irrelevant because of our tools. With respect to expendable C# code is a string. It's all in who, when, where, how, why parsing is done.

Kathleen