Proposal: Named lambda/Action/Func

[larslarsson]

Allowing one to name the method name for lamdba:s/Action/Func to allow for better traceability & logging. E.g. keep current implementation but allowing override of it.

Output:

MyMethod
<Main>b__0_0

Code:

void Main()
{
	LogMethod(MyMethod);
	LogMethod(() => MyMethod2("dummy"));
}


// Define other methods and classes here
public static void MyMethod()
{
	
}

public static void MyMethod2(string arg)
{

}

public static void LogMethod(Action action)
{
	action.Method.Name.Dump();
}

Another feature ontop of: #269

[HaloFour]

You're access the raw Method to which the delegate is pointing, so you're getting the actual name of the method that the C# compiler emits to support the lambda. That name is an implementation detail and not a part of the spec. It can't be some arbitrary friendly name otherwise it would clash with the names of any methods in the scope of the class in which the method declaring the lambda is defined.

[larslarsson]

Sometimes having wrapped try catches & stuff or other wrappings (internal vs public etc).
Does the name really have to be unique, doesn't it have its own typing anyway to make it distinct, not bound to declaring class/object.

[larslarsson]

Same thing with tasks, option to giving them names. SO suggests extension with weak ref. as only option today.

[HaloFour]

@larslarsson

Does the name really have to be unique, doesn't it have its own typing anyway to make it distinct, not bound to declaring class/object.

The name is indeterministic and an implementation detail. It does have to be unique as each lambda requires its own method and those are declared in a specific class based on what they enclose or if they are cached. All of this is implementation details that are not a part of the specification, though, and code should never rely on the name or shape of the methods that are emitted by the compiler.

What exactly are you proposing the name of the method of the lambda be in your example, by the way?

[larslarsson]

In my case allowing the user (me) to supply override but that would not be wise if it internal constraint like you talk about. I guess Task would be fine to do that as its a class & more code moves in that direction & simplifies debugging.

My specific case was a worker thread/dispatcher logging about a task was slow, was kind of okay until i wrapped it to not break/extend interface. Could of course be solved by using seperate class to contain name & action/task but nice if built in since quite often one pass action/func/task around. Kind of like I presume there must be plenty of tickets about default dictionary not telling what key is violated - can be solved but nice to have.

From glancing over topics of discussed propsals like the linked one, is it correct to interpet them as making lambda as an actual/C# internal type & then it opens up for changes such as this without constraints? Or simply never possible.

[HaloFour]

@larslarsson

From glancing over topics of discussed propsals like the linked one,

As far as I can tell the linked proposal is only about an alternate syntax for working with the Action<...> and Func<...> family of delegates.

[larslarsson]

Well if not possible close. If not feasible close, maybe it will remain in the back of the head if something changes in the future. Voiced a opinion/nice to have & got a reply so I am happy.