Proposal: Allow Lambda as Argument to an Attribute

[gafter]

@sirisian commented on Sat May 02 2015

Essentially allow lambdas as arguments to attribute constructors.

Code example. Specifically the "[Converter(s => s == "one" ? 1 : 0)]" line and "public ConverterAttribute(Func<string, int> converter)" in the constructor.

Possible use cases I've seen from years ago are converters for serialization libraries and alternative ways to define validator functions.

using System;
using System.Linq;

namespace AttributeTest
{
    [AttributeUsage(AttributeTargets.Property)]
    public class ConverterAttribute : System.Attribute
    {
        public Func<string, int> Convert
        {
            get;
        }
        public ConverterAttribute(Func<string, int> converter)
        {
            this.Convert = converter;
        }
    }

    class BaseItem
    {
        public int GetTotal()
        {
            return this.GetType().GetProperties().Select(propertyInfo => ((ConverterAttribute)propertyInfo.GetCustomAttributes(typeof(ConverterAttribute), true).First()).Convert((string)propertyInfo.GetValue(this))).Aggregate(0, (input, value) => value + input);
        }
    }

    class DerivedItem : BaseItem
    {
        [Converter(s => s == "one" ? 1 : 0)]
        public string Foo
        {
            get;
            set;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var convertedItem = new DerivedItem();
            convertedItem.Foo = "one";
            Console.WriteLine(convertedItem.GetTotal());
        }
    }
}

---

@HaloFour commented on Sat May 02 2015

C# is limited by the CLR in the types of the parameters that can be used for custom attributes. Those values need to be easily and predictably serialized/deserialized as they are embedded as a BLOB directly in the assembly metadata and reconstructed by the run time. The compiler could probably emit anything it wanted in the BLOB but the CLR itself can only understand and deserialize the integral types, bool, char, string, Type (serialized as a string of the type name) and arrays of those types.

Given that, how would a lambda be embedded? They can't really be serialized, even if the limitation on the CLR could be lifted. Only thing I could think of is that the compiler generates a synthetic public type with a public static method and then serializes the method runtime handle. The attribute itself would have to be defined in a way that the property is really of long so that the CLR would deserialize the value of the method handle which would be converted to a RuntimeMethodHandle and MethodBase.GetMethodFromHandle called to obtain the MethodBase which is then converted into a delegate, but how to make that seamless sounds messy.

---

@MaulingMonkey commented on Wed Mar 15 2017

"Only thing I could think of is that the compiler generates a synthetic public type with a public static method"

This is basically how lambdas already work. For:

using System;
using System.Collections.Generic;
using System.Reflection;

static class Program
{
	public static void Main(string[] args)
	{
		var l = new List<int>() { 1, 2, 3 };
		l.RemoveAll(i => i%2 == 0);
		foreach (var i in l) Console.WriteLine(i);
	}
}

Roughly the following is generated:

private class <>c
{
	public <>c() {}
	internal bool <Main>b__0_0(int i) { return i%2 == 0; }

	public static <>c <>9 = new c<>();
	public static Predicate<int> <>9__0_0 = new Predicate<int>(<>9.<Main>b__0_0);
}

Multiple lambdas may be collapsed into a single class (depending on if they share the same captured state? - none in this case...)

System.Runtime.Serialization.Formatters.Binary.BinaryFormatter can currently (de)serialize delegates - presumably by persisting the object instance and method name or similar, although this is potentially rather brittle. A less general purpose method that might work here (by virtue of being unable to capture local method state when constructing attributes, and thus always being able to generate a static delegate instance to reference) would be to simply persist the name of the static field ("<>c.<>9__0_0").

[ronnyek]

I know the reasoning for some of this, and at the same time don't pretend to be an expert on the subject matter. I for one think this would be really cool functionality to allow some better support for conventional stuff. I don't see myself trying to put complex logic inside of the lambdas but would love to be able to do stuff like

[Validate(x=> x>0)] or even be able to just reference a constant lambda/expression/func as a sort of property accessor.
[ValidationFunction(x=>x.ValidateUser)]

I've seen people simulate this with the method name as a hard coded string... and you could do things like make sure those are re-used constants, but seems like even basic support for soem form of lambda would be huge.

[jnm2]

If we were going to do something, I wish we could have [ValidationFunction(ValidateUser)]. Lambdas are verbose and too open-ended. We used lambdas to indicate members because it was the only thing that worked and had some compile-time checking, not because it was a good abstraction. If we could have a BCL type other than Expression<>, perhaps even MethodInfo, EventInfo, PropertyInfo, etc, holding a first-class reference to the member that was fully checked at compile time, understanding the context of the declaring type so that you only have to type ValidateUser, that would be stunning.

It would be a big new language feature though.

And it would find great use in places other than lambdas- testing frameworks, binding/mapping frameworks, etc.

[alrz]

Even [ValidateFunction(nameof(ValidateUser))] works (because you already need reflection for the attribute itself). Anyways, I'd rather be able to instantiate objects (records, mostly) in attributes,

[SomeAttribute(SomeRecord(SomeOtherRecord(1)))]
void M(){}

afaik this is possible in Java, but it requires all nested objects to be annotations as well.

[Pzixel]

you already need reflection for the attribute itself

It's not true if your logic in the attribute itself. Simple example : action filter in MVC that takes a predicate to validate. You don't need reflection inside OnActionExecuting, and you don't care how you get called. No reflection on your side here. If you have method name only things start be weird.

What's about other types? DateTime/TimeSpan/Decimal are candidates number one for being attribute members.

Yet another question: what's about Expressions inside attributes? For example:

[SomeAttribute(() => true]
void M(){}

public class SomeAttribute : Attribute
{
	public SomeAttribute(Expression<Func<bool>> expression)
	{
		
	}
}

[Joe4evr]

DateTime/TimeSpan/Decimal are candidates number one for being attribute members.

DateTime works today, but only in VB because that has DateTime literals, IIRC (and uses a serialization trick at runtime). Decimal could potentially work in the future if the runtime gets an update to reliably deserialize one (which is not the case right now, hence you can't declare a const decimal).

[Pzixel]

@Joe4evr but you can have const decimal :) Of course, on an IL level it's just a compiler trick and it can be changed in some dark magic ways via reflection, but it's quite useful for fair use, just like readonly fields are. It's always an option to store it in in InvariantCulture string representation and just (de)serialize when needed. It's all up to compiler, probably it how it's working in VB. Decimal may be stored just like a byte array (as it does today for consts IIRC)

[HaloFour]

@Joe4evr @Pzixel

You can only have "constants" of decimal (and DateTime in VB.NET) where the compiler can control the initialization of the value. For example, they're permitted for default parameter values because it is the job of the compiler at the call site to negotiate the metadata of the method, extract the default value and embed it in the invocation. However, when it comes to attributes it's the CLR that is responsible for actually instantiating the attribute class at runtime, and in that case neither decimal nor DateTime are permitted because the CLR has no concept of those language-specific hacks.

[Pzixel]

@HaloFour what if compiler just generates the constructor that accepts byte array and perform all transformations? For example:

[AttribuAttribute(10)]
class Foo { }

class AttribuAttribute : Attribute
{
    public AttribuAttribute(decimal value)
    {
        // user code here
    }
}

becomes:

[AttribuAttribute(new byte[] {01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 0A, 00, 00, 00, 00, 00})]
class Foo { }

class AttribuAttribute : Attribute
{
    public AttribuAttribute(byte[] value) : this(CompilerSerivce.ConvertSomehow(value))
    {
        
    }

    public AttribuAttribute(decimal value)
    {
        // user code here
    }
}

[Timwi]

I do feel the need to point out that the CLR spec change required is small, and the C# compiler doesn’t have to do much. A lambda expression translates to a static method and then (in IL) it’s just a metadata token, which is an integer. This much is already in the C# compiler right now.

Thus, on the CLR side, the only extensions required are 1) to allow metadata tokens as arguments to an attribute constructor parameter that expects a delegate, and 2) have it instantiate the relevant delegate type when it invokes the custom attribute constructor. The delegate type is already available (because it’s the type of the parameter) and the CLR already has access to a delegate constructor that accepts a metadata token (which is hidden from C#).

On the C# side, the compiler only needs to serialize the (already existing) metadata token when serializing the attribute constructor arguments.

There is no complex serialization of an entire method or expression tree necessary on neither the C# or the CLR side.

[ghost]

+1

[mikernet]

I would just like to throw in my +1 on this - it would be incredibly useful. I know from other discussions that this is probably a fairly low priority item for the team, but this would open up SO MANY possibilities that aren't immediately obvious...the community would explode with libraries that make use of this to enable advanced meta programming scenarios that aren't possible to do cleanly at the moment.

[NathanMCarlson]

Not sure where this stands, but I'll throw in my +1 as well. Another recent example: dynamic aspect-oriented programming using interception, for logging. I can construct an interceptor that, for instance, logs method errors, like this:

[LogThis]
public object MyMethod( object input )
{}

// ...

public class LogThisAttribute : InterceptAttribute
{
   // ...
   public override IInterceptor CreateInterceptor(IProxyRequest request)
   {
      // do logging here
   }

...but if I wanted to vary the approach there's no way to do that from the attribute. It would be nice to be able to do something like this:

[LogThis( (className, methodName) => $"{className} {methodName} invocation" )]

Makes that attribute much more flexible.

[alrz]

Couldn't this work? [LogThis( "{ClassName} {MethodName} invocation" )]

[admalledd]

Adding a bit more on my desire for this. I actually would prefer/require it be a lambda expression (or at least support that) since that is the main desire the platforms/frameworks/tools I create/maintain for my work would greatly desire.

public class ResourceAttribute<TResource> : Attribute
{
	public ResourceAttribute(LambdaExpression<Func<TResource, TProperty>> expression)
	{
		//basically get the PropertyName of TResource for future code-gen magic, or pure reflection if not.
               // https://github.com/dotnet/roslyn/issues/19505
	}
}

public class FooBar
{
    [ResourceAttribute<RealResourceManagerType>(rm => rm.SomeRelatedResourceProperty)]
    public string SomeMember { get; set; }
}

Leveraging assumed "Generic Attributes" #124 although similar-but-more-obtuse could be done with just the lambda expression (thus also parse/figure out the TResource or such)

I remember discussing over a year ago with someone closer to the compiler and assembly CIL/assembly format that "Encoding an ExpressionTree might be simpler than a delegate, especially with respect to referencing other types." I could be wrong here though, anyone know much for certain?

With an (Lambda)Expression whoever wants executable code can .Compile() the Expression. Interacting with Attributes already means a bit of reflection, so adding .Compile() & caching wouldn't be much additional cost vs what I assume as being possibly easier to encode in the assembly?

I also have quite a number of reasons for wanting this that involve simple validators relying on properties (not just "in range of constants" or "is positive"), that others have mentioned here-there but I don't see a code example directly:

public class FooViewModel
{
    public int SomeNumber_A { get; set; }

    // B must be null, or larger than A, enforced elsewhere in semi-custom validation middle-layer
    [Validation<FooViewModel>(e => e.SomeNumber_B == null || e.SomeNumber_B > e.SomeNumber_A)]
   public int? SomeNumber_B { get; set; }
}

[BreyerW]

@admalledd if im not mistaken expressions (with compile() - without it should work but thats barely useful) wouldnt work in AOT scenarios

Another problem is that these expressions got discontinued (a shame but cest la vie) and will not be evolved in future meaning that supporting/relying on it is likely a bad idea

[svick]

@BreyerW

if im not mistaken expressions (with compile() - without it should work but thats barely useful) wouldnt work in AOT scenarios

They will, using an interpreter. That might not have the performance that you need, but it does work.

Another problem is that these expressions got discontinued (a shame but cest la vie) and will not be evolved in future meaning that supporting/relying on it is likely a bad idea

It's true they're not being kept up-to-date with language additions, but that doesn't mean they're discontinued or that they shouldn't be used. They are still a supported part of the language.

[BreyerW]

@svick ah right but nowadays interpreter is also incomplete if i remember correctly (at least i believe mono interpreter used to be lacking some features since it didnt mirror 100% traditional reflection maybe thats has changed since then) probably could be completed but since it wasnt done from the start theres high chance its not trivial. And of course performance hit is nontrivial too

And regarding discontinuity - i used this word on purpose instead of obsolete. Its supported in runtime but it was announced in old dotnet corefx its not going to be evolved meaning lack of certain features forevermore (refs for example from the top of my mind and any future ones like shapes) unless this package gets unfreezed and be back on the menu

Edit More specifically it was done in old corefx and got freezed along with various other packages that they believed to be mature enough that evolving is no longer necessary for them

[tonygiang]

+1

In Unity, we often use an attribute to automatically search and cache all assets containing a particular class in a serialized form. This works well for a dumb search, but things start to get complicated when mixed in with those assets are "templates" - assets we derive from to streamline new asset creation. We don't want to include the "template Bullet" in the list of all Bullets to be used in the final game, for example. This calls for some sort of filter in the auto cache attribute itself.

We could make our own filter condition as a field in the auto-cache attribute class, but this could balloon the auto-cache attribute class really quick as more asset types require different filter conditions, plus it would destroy the re-usability of the class itself.

If we can just pass a lambda into the attribute constructor, most of this boilerplate can be reduced and promotes DRY principles.

[acaly]

What version of C# can Unity use today?Can it benefit from new features of .NET Core?

[tonygiang]

Unity currently uses 7.3 in its latest LTS version and there is plan to upgrade to newer .NET version.

[sacalata]

+1

how come this is not on NET6 already?, attributes are awesome, easy to read and reduce syntax, any improvement to them its a big plus for me

[6a6f6a6f]

One cool thing this feature will allow is with Spectre.Console, making the possibility of creating command-line tools in various languages and every other library that relies on annotation for that use-case. I'm aware you can do this on System.CommandLine.

I hope this becomes a feature on .NET 7.

[RikkiGibson]

Could you provide some hypothetical samples of the API patterns that would be enabled?

[ronnyek]

Strongly typed references to an objects properties without using a string.

Similar to validation examples above, I care less about providing actual expressions as parameters to an attribute, but more just being able to point at a property of the type.

Eg.

[Except(x=>x.Age)] // this is just better in so many ways than "Age" as a parameter

I get that I could just have attributes that get assigned to the properties themselves, but the idea here would be that this attribute would be applied at the class level to a class inheriting from another class I wouldn't want to pollute with attributes at the parent level.

If there are already ways to handle this, I'm all for that as well.

[Joe4evr]

Strongly typed references to an objects properties without using a string.

That's what nameof() is for.

[admalledd]

With respect, nameof() is a bit of a kludge, and you don't see EF and such using it. Using ParameterExpression tree is far more preferable for a number of reasons. Relying on nameof() means that users of an API can still pass in a normal string, which is some of exactly what the point of the request is about solving.

[AathifMahir]

+1

[cAttte]

+1