Metadata Attributes on Lambda Expressions

[AdamSobieski]

I would like to propose for consideration some syntax for utilizing metadata attributes on lambda expressions such that compiled-to methods would be decorated or adorned with the custom attributes.

For an example scenario:

Expression<Func<int, int, int>> expr = (int x, int y) => x + y;

one could adorn a lambda expression with attributes:

Expression<Func<int, int, int>> expr = [MethodMetadata] (int x, int y) => x + y;

one could decorate or adorn the parameters:

Expression<Func<int, int, int>> expr = ([ParameterMetadata] int x, int y) => x + y;

and one could decorate or adorn the return value:

Expression<Func<int, int, int>> expr = [return: ReturnMetadata] (int x, int y) => x + y;

These can work in combination:

Expression<Func<int, int, int>> expr =
  [return: ReturnMetadata]
  [MethodMetadata]
  ([ParameterMetadata] int x, int y) => x + y;

The attribute usage for the attributes upon lambda expressions would be that for methods, as the resultant attributes decorate or adorn the compiled methods.

With C# language syntax resembling that indicated above, one could compile lambda expressions and resultant methods would be decorated or adorned with specified metadata attributes. This would be useful when developers desire to make use of metadata attributes and to utilize compiled and runtime-compiled methods interchangeably.

[svick]

What are the use cases where attributes on the method that is called when you invoke a delegate matter?

[AdamSobieski]

@svick, there are plenty of use cases. A few are indicated:

1. To annotate a lambda expression with a display name or stack-trace name. This topic was recently broached in issue Proposal: Custom names for lambdas in Stacktraces #3087. I adjusted the example syntax from that issue’s discussion thread, adding parentheses to the lambda expression parameter to avoid ambiguity between on-method and on-parameter decoration:

void Main()
{
  new Test().GetNumber(new[] { 4, 1, 3, 2, 5 },  ienum => ienum.OrderBy(i => i).Where([StacktraceName("GetNumberLambdaWhereCondition")] (i) => i != 2 ? throw new Exception("Stacktrace") : true).First());
}

class Test
{	
  public int GetNumber(IEnumerable<int> ienumerable, Func<IEnumerable<int>, int> predicate)
  {
    return predicate(ienumerable);
  }	
}

void Main()
{
  new Test().GetNumber(new[] { 4, 1, 3, 2, 5 },  ienum => ienum.OrderBy(i => i).Where([DisplayName("GetNumberLambdaWhereCondition")] (i) => i != 2 ? throw new Exception("Stacktrace") : true).First());
}

class Test
{	
  public int GetNumber(IEnumerable<int> ienumerable, Func<IEnumerable<int>, int> predicate)
  {
    return predicate(ienumerable);
  }	
}

2. One might desire to decorate or adorn runtime-compiled methods with their source code. This could be useful for meta-programming scenarios or for varieties of optimizations.

[CompilerGenerated]
[Rule]
[HasForm("f3(X, Y) := f1(X), f2(Y).")]
public static IEnumerable<bool> f3(Term X, Term Y)
{
  // ...
}

[Rule] [HasForm("f3(X, Y) := f1(X), f2(Y).")] [DisplayName("f3")] (Term X, Term Y) => ...

3. One can envision scripting scenarios where source code files and line numbers could be indicated in the metadata decorating a runtime-generated method.

4. A number of scenarios could utilize the method implementation attribute, including specifying JIT optimization or inlining preferences for a runtime-generated method.

[MethodImpl(MethodImplOptions.AggressiveInlining)] (int x, int y) => x + y;

5. Adding these language features would require extending LambdaExpression, e.g. adding some properties and constructors, so there would also be use cases which involve the construction of expression trees and lambda expressions.

[CyrusNajmabadi]

At thsi point, it's somewhat defeating the point of lambdas (small, lightweigh pieces of code). I'd just as soon use a local-function if it's going to need so much ceremony.

[AdamSobieski]

C# lambda expressions may have originally been designed and intended for lightweight scenarios, e.g. LINQ.

Extending the System.Linq.Expressions abstract syntax tree model appears to be a popular topic in this forum, and for a number of reasons / scenarios.

A scenario which is both useful and interesting to me is that of runtime code generation, constructing LambdaExpressions at runtime and then compiling them.

In addition to LambdaExpressions, Roslyn can be of use for runtime code generation [1][2][3] and a new .NET feature is that runtime-generated assemblies are collectible [4].

On the topic of local functions vs. lambda expressions, I found this: https://docs.microsoft.com/en-us/dotnet/csharp/local-functions-vs-lambdas .

[1] https://josephwoodward.co.uk/2016/12/in-memory-c-sharp-compilation-using-roslyn
[2] http://www.tugberkugurlu.com/archive/compiling-c-sharp-code-into-memory-and-executing-it-with-roslyn
[3] https://www.strathweb.com/2018/01/easy-way-to-create-a-c-lambda-expression-from-a-string-with-roslyn/
[4] https://www.strathweb.com/2019/01/collectible-assemblies-in-net-core-3-0/

[svick]

Most of those use cases sound purely hypothetical to me, I don't think it makes sense to add a feature to the language that could be useful, there has to be a near certainty that it will be useful to a sufficiently large number of developers.

Specifically:

1. As has been mentioned in Proposal: Custom names for lambdas in Stacktraces #3087, if it's really important for you to give a name to a lambda, you can use a local function instead, the extra ceremony involved in that isn't that much.

2. This seems to be specific to some tool you're working on. But I don't see a reason why that tool has to generate lambdas, instead of local functions or methods. (Note that local functions can't currently have attributes either, but that's likely to change in C# 9.0: Champion "Permit attributes on local functions" (VS 16.8, .NET 5) #1888.)

3. Such information is already preserved in PDB files. Why would we need a different mechanism for lambdas?

4. Similarly to #2 above, if you need this, I think using a method or a local function is sufficient.

5. The cases involving expression trees seem to be very convoluted to me. I think it would require a process where you generate C# code with expression trees and then at runtime, inspect the method that resulted from compiling the expression tree for some further processing.

   Even if there is no better way to provide the extra information (and I'm not sure about that), I can't imagine this would be widely useful.