strong typed CallerAttributes like CallerMemberName CallerArgumentExpression

[qsdfplkj]

Background and motivation

I have to create a couple of methods that require me to know the CallerMemberName and CallerArgumentExpressions. But because those are all just strings I might be calling an unintended wrong overloads as they are implemented with a string parameter.

Suppose I have:

public static void Print<T>(T message, [CallerMemberName] string memberName = "")
{
    Console.WriteLine($"{memberName}: {message}");
}

public static void Print<T1, T2>(T1 message, T2 value, [CallerMemberName] string memberName = "")
{
    Console.WriteLine($"{memberName}: {message} {value}");
}

Print("Hello", "World") // will call the wrong (first) method
Print("Hello", 123) // will call the correct (second) method

I guess the same holds for CallerArgumentExpresssion

public static void Print<T1, T2>(T1 message, T2 value, [CallerMemberName] string memberName = "", 
[CallerArgumentExpression(nameof(value))] string argumentExpression = "")
{
    Console.WriteLine($"{memberName}: {message} {argumentExpression}={value}");
}

public static void Print<T1, T2, T3, T4>(T1 message, T2 value, T3 value2, T4 value3, [CallerMemberName] string memberName = "", [CallerArgumentExpression(nameof(value))] string argumentExpression = "")
{
    Console.WriteLine($"{memberName}: {message} {argumentExpression}={value}");
}

int World = 123
Print("Hello", World); // This will work but 
Print("Hello", World, "Hello", "Again");  // this will call the wrong (first) overload

API Proposal

To prevent all those incorrect calls I propose using strong type parameters that just behave as string but prevent these issues.

I would like to make it clear it is intentional:

    public static void Print<T>(T message, [CallerMemberName] MemberName memberName = "")
    {
        Console.WriteLine($"{memberName}: {message}");
    }

    public static void Print<T1, T2>(T1 message, T2 value, [CallerMemberName] MemberName memberName = "")
    {
        Console.WriteLine($"{memberName}: {message} {value}");
    }

such that:

Print("Hello", "World") 
Print("Hello", 123) 

will call the correct overloads because the callermembername is strong typed.

Print("Hello", "World", (MemberName)"someothername")  // makes the call intentional.

where we have a predefined types/structs

public class (Caller)MemberName // TBD: use caller prefix is there a scenario where MemberName might be reusable?.
{
    private string _value;

    public MemberName(string value)
    {
        _value = value;
    }

    public static implicit operator string(MemberName memberName) => memberName._value;

    public static explicit operator MemberName(string value) => new MemberName(value);

    public override string ToString()
    {
        return _value;
    }
}

And for argumentexpression use the same approach, and others like CallerLineNumberAttribute

API Usage

Using it is pretty straight forward, use the strong type.

E.g.

    public static void Print<T1, T2>(T1 message, T2 value, [CallerMemberName] MemberName memberName = "", 
    [CallerArgumentExpression(nameof(value))] ArgumentExpression argumentExpression = "")
    {
        Console.WriteLine($"{memberName}: {message} {argumentExpression}={value}");
    }

Alternative Designs

No response

Risks

Make it work backwards compatible and show a message or warning if the new API is not used. It will help people from making mistakes.

[huoyaoyuan]

Generally in BCL we do not use the pattern to create alias for primitive types.

But because those are all just strings I might be calling an unintended wrong overloads as they are implemented with a string parameter.

This can easily be supported by an analyzer with warning.

[qsdfplkj]

Generally in BCL we do not use the pattern to create alias for primitive types.

But because those are all just strings I might be calling an unintended wrong overloads as they are implemented with a string parameter.

This can easily be supported by an analyzer with warning.

I guess that part is true, but the case where we have to resolve the correct overload isn't solved.

public static void Print(string message, [CallerMemberName] string memberName = "")
{
    Console.WriteLine($"{memberName}: {message}");
}

public static void Print(string message, string value, [CallerMemberName] string memberName = "")
{
    Console.WriteLine($"{memberName}: {message} {value}");
}

public static void Test()
{
    Print("Hello", "World"); // This will still select the first one.
}

[yaakov-h]

This would be very difficult to solve entirely due to backwards compatibility with existing string functions, but I think #7906 may help here to change the overload resolution priority?