Home Dashboard Directory Help
Search

Allowing Expression<T> in attributes parameters. by AyendeRahien


Status: 

Closed
 as Won't Fix Help for as Won't Fix


38
1
Sign in
to vote
Type: Suggestion
ID: 254057
Opened: 1/26/2007 6:57:54 AM
Access Restriction: Public
0
Workaround(s)
view

Description

What I would like to enable is declarative pre/post conditions, as well as validation.
The idea is to allow declarative conditions, which can be checked by a framework.
At the moment, Expression<T> (where T is a valid delegate type) is not a valid attribute parameter type.
My understanding of the way Expression<T> works hints that it is possible to make this work, by serializing the expression tree generated by the compiler into the attribute data, and then restoring it afterward.
This probably requires changing the spec, because currently valid attribute parameters include primitives, string, Type and enums.
Nevertheless, I consider this as a great feature which can open up many possibilities for declarative programming.
Details
Sign in to post a comment.
Posted by Stefan Wenig on 3/22/2009 at 6:18 PM
This is a special case of 425856: Remove C# attribute restrictions, including generics and argument types
Posted by Microsoft on 4/24/2008 at 4:38 PM
Thanks again for your suggestion. After having done feature planning for the next release of C# I regret to say that this feature is not being added. We have to do some harsh prioritization, both because of our implementation and testing resources, but also because we need to keep the number of new langauge features at a manageable level - depending on how you count, we are adding only four language features to C# this time around. Unfortunately many great suggestions just can't make it in because of that.

I apologize that this is a "canned" follow-up answer, sent out as a result of our feature planning for the next release. In most cases I or someone else already replied individually to your suggestion - please let us know if you feel it hasn't been adequately addressed.

Thanks again for taking the time to share your ideas with us. Please keep them coming!

Mads Torgersen, C# Language PM.
Posted by Stefan Wenig on 8/16/2007 at 4:18 AM
this can currently be achieved by replacing the attribute with a subclass.

instead of:

[IsValid (x => x == null)]
public string name;

you write:

[IsNameValid]
public string name;

private class IsNameValidAttribute: IsValidAttribute<string>
{
IsValidAttribute() : base (x => x == null);
}

The compiler could probably do this straightforward transformation quite easily.

(only that the base class cannot be generic either, but that's a different topic. i sugested this in https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=293594. this should be solved too, or the current suggestion would be of limited use.)
Posted by Microsoft on 8/3/2007 at 1:26 PM
Ayende -

Thanks for sending in this suggestion. Apologies for not replying to this sooner - the bug has been sent between a few different teams while we've been in the process of discussing this issue - and we unfortunately let it slip by without sending an external update.

First things first: We really want to support this. We know it's important for a lot of scenarios. We are aware of multiple internal and external projects which could benefit significantly from enabling this.

However, there are some significant issues we are trying to tackle in terms of how to make this a reality. I'll describe some of the details below - but the short story is that we will not be able to enable this in Orcas. We are however actively investigating this for the next version of the C# language and the LINQ APIs.

Details:
1) Attributes are very limited: They are a low level concept in the runtime, which has a lot of restrictions in terms of the kind of data that can be stored. Arbitrary objects cannot be stored in attributes.
2) Expression trees are fundementally *not* serializable: They can have pointers out to arbitrary in-memory objects (such as in Constant nodes, but also elsewhere) and contain large amounts of reflection data. Although a serialization scheme can likely be built to serialize/deserialize a reasonable percentage of expression trees - a 100% fidelity process is not within reach.
3) The combination of the first two means there is no direct way to put expression trees into atributes. The two concepts just don't play well together.

We're looking at some other ways to approach this - but they would require either runtime changes or non-trivial C# language/compiler changes. Since both of these need to wait till our next product cycle - I'm moving this tracking suggestion to the Post-Orcas milestone.

Thanks again for the suggestion.
Luke Hoban
Visual C# Compiler Program Manager
Sign in to post a workaround.