Proposal: Add CallerType to Caller Information attributes

[timothyBoye]

Summary

Caller Information attributes include CallerFilePath, CallerLineNumber, CallerMethodName, and CallerArgumentExpression. It is requested that CallerType representing the value typeof(Caller) be added to the caller information attributes.

Previous discussions have occurred at #87 and LDM. These appear to have been overly ambitious, however the core proposal warrants further consideration.

Details and Motivation

Caller information attributes are used for debugging, logging, and various other tasks. While the current set of properties is very useful for these, it is not possible to reliably infer the type of the caller from the current set.

As an example, it would be beneficial to be able to log not just the name of a caller but the type where subclassing is involved. This would make it clear which sub class the logging is related to where the inherited property or method would always have the same CallerMethodName e.g.,

// code is for demonstration purposes and not intended as perfect C# code

abstract class Foo {
   [CustomAttribute]
   IExamplable Example = new Example1();
}

class Bar : Foo {
   [CustomAttribute]
   override IExamplable Example = new Example2();
}

Class CustomAttribute : Attribute {
   public CustomAttribute([CallerType] IExamplable type) {
      // custom logic related to the types
   }
}

Doing some googling on ‘csharp custom attributes type’ and similar queries it is clear there is a sizeable contingent of developers looking for ways to get the type of the caller in custom attributes (myself included). Typically it appears this is related to switching on type for custom logic, both as in the inheritance example above as well as in more generic cases e.g.

class Foo {
   [FormField]
   Public string Name;
   [FormField]
   Public int Age;
}

Class FormField : Attribute {
   Public FormField([CallerType] Type type) {
      // custom logic related displaying a form field based on type of field (not unrelated to how in ASP.NET Core you might set the DisplayName attribute but with some further customisation based on type)
}

Based on previous discussions including the LDM notes, it appears the main concern is bloating of the Caller Information as previous proposals have taken a laundry list approach hoping something will stick. Most previously requested Caller Information can however be achieved through Type alone, limiting the expansion of the Caller Information to one additional attribute (e.g., type name, full type name etc).

There was some suggestion that providing the caller object itself would provide all the information one could need including a way to get the type easily and thus would be the superior all encompassing Caller information. However, this comes with a lot of baggage and would likely lead to the same concerns listed in the LDM notes. While I can see many ways this could be useful, I suggest that Type covers the vast majority of requests discussed while in comparison significantly limiting potential concerns and therefore is a reasonable middle ground.

[huoyaoyuan]

Information about compiled result (Type) is more complex than information about source code (filename, line). A method can belong to compiler synthesized type like closure of lambda.

[Flithor]

Example:

void A([CallerMemberName] string caller = default) => Console.WriteLine(caller);
void ExecLambda(Action act) => act();
void Test() => ExecLambda(() => A());

Quesion: What is the output of calling "Test"?

> Test

Looks like its value is explicitly defined as the name of "named method" or the property getter or setter it is in.
(Replace with a constant string during precompilation)
If based on runtime context will get an unstable result.