Interpolated string handler method names

[333fred]

Interpolated string handler method names

Champion issue: #9046

Summary

We add support for interpolated string handlers to receive a new piece of information, the name of the method they are an argument
to, in order to solve a pain point in the creation of handler types and make them more useful in logging scenarios.

public void LogDebug(
    this ILogger logger,
    [InterpolatedStringHandlerArgument(nameof(logger), "Method Name")] LogInterpolatedStringHandler message);

[yaakov-h]

I'm thinking about the way that this might evolve if the method and handler are split across different assemblies, and wondering if it would be better to annotate the handler as "I need the name of the method being invoked", rather than the calling method being annotated as "please pass the my name into the handler"

e.g. something like:

public ref struct LogInterpolatedStringHandler
{
    public LogInterpolatedStringHandler(..., [CallingMemberName] string methodName, ...) { ... }
}

[colejohnson66]

Except interpolated string handlers are constructed/filled by the method that calls LogDebug, not by LogDebug. So, in this example, the "calling member name" is "DoTheThing", not "LogDebug":

public void DoTheThing()
{
    _logger.LogDebug($"Property: {SomeProperty}.");
}

[yaakov-h]

Yes, I wrote a new attribute there CallingMemberName rather than CallerMemberName. Name can be bikeshed to the moon and back.

Point is that the compiler would see an attribute and emit something more like:

public void DoTheThing()
{
    var message = new LogInterpolatedStringHandler(11, 1, nameof(_logger.LogDebug)); // pass to constructor since the InterpolatedStringHandler type requested it
    _ = message.AppendLiteral("Property: ") && // Short-circuit by returning false if name is LogDebug but debug logging is not enabled
        message.AppendFormatted(SomeProperty)) &&
        message.AppendLiteral(".");
    _logger.LogDebug(message);
}

[333fred]

While we could take this approach, it's significantly more work for no real gain. We already have an attribute to specify arguments to the handler constructor, in order, and already have one magic string for additional things beyond just params. A CallingMemberNameAttribute would have no real use case beyond this one scenario, need to be bikeshed to the moon back in terms of naming, and we'd need to design the semantics of what would happen when the handler is used outside of a method. If we were going to go to that level of work, I'd rather just go all the way and design the full arbitrary constant-passing system.

[yaakov-h]

That makes sense. It just seems odd to me that part of the contract of the class becomes "also use it with this attribute setup every single time otherwise you get a compiler error". Seems simpler to me to embed that in the handler itself.

[colejohnson66]

While I agree with the premise of the proposal, and want a solution, I, personally, loathe the idea of a magic string. It's already confusing enough that "" means the this instance. If we are going to have a magic string, it should be available as a const somewhere.