Self-documenting expressions in interpolated/formatted strings

[gukoff]

What

One can extend syntax of interpolated strings with a = specifier. When present, = would make the expression in curly braces part of the resulting string.

In simple words, instead of writing:

Console.WriteLine($"File path: {myfile.FullPath}, file length: {myfile.Length}");

// File path: C:\NewFile.txt, file length: 100

One could write:

Console.WriteLine($"{myfile.FullPath=}, {myfile.Length=}");

// myfile.FullPath=C:\NewFile.txt, myfile.Length=100

Why

This significantly eases debugging when logging with Console.WriteLine, logger.LogDebug, VS tracepoints, etc.

When adding a trace, one automatically gets a sensible log message that includes context. One doesn't need to come up with a lengthy message template and type it out.

More examples

$"{isLarge & isGreen =}" // => "isLarge & isGreen = true"

$"{myObj.Exists()=} {anotherObj.Exists()=}" // ​=> "myObj.Exists()=true anotherObj.Exists()=false"

Also...

• This seems to be a non-breaking change.
• I believe it would work with composite formatting too, not only interpolated strings.

---

This idea is borrowed from Python 3.8+:
[1] https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging
[2] https://bugs.python.org/issue36817

[FaustVX]

I don't think "print debugging" should be favorized.
There are other method for debugging (breakpoint, trace point, trace Log, …) which are created for easing the debugging.
So adding a simple solution encourage the use of "print debugging".

[gukoff]

I realized that "print debugging" is a misleading definition. I edited the initial post to emphasize that it benefits any kind of tracing through the log messages.

So adding a simple solution encourage the use of "print debugging".

Good for you, if it makes your life better! 😉
There is no bad debugging tool, and making any of them simpler is a great productivity boost.

[FaustVX]

Maybe with the CallerArgumentExpression proposal, you could write something like:

public static string Evaluate(object value, [CallerArgumentExpression("value")] expression = null)
    => $"{expression}={value}";

Console.WriteLine(Evaluate(myfile.FullPath) + ", " + Evaluate(myfile.Length)); // => "myfile.FullPath=C:\NewFile.txt, myfile.Length=100"

And bonus: you could customize it to whatever you like: maybe : instead of =, add spaces, …

[gukoff]

CallerArgumentExpression is indeed close in spirit. Maybe these features could share part of the implementation.

But their use cases are different. The need to define and call a new function would defeat the purpose of this proposal :)

[FaustVX]

Also, the fact that this syntax is tied to interpolated strings, seems a little odd to me (eg: for a single value, you have to use this syntax $"{myValueExpr=}").
The interpolated strings is just syntactic sugar over string.Format.
CallerArgumentExpression is just like others Caller…Attribute.

[Richiban]

You can get reasonably close to this now by using an anonymous object. Performance should be fine outside of any tight loop scenarios:

	var fileName = "file.txt";
	var filePath = @"c:\files";

	Console.WriteLine($"Values: {new { fileName, filePath }}");

Which prints: Values: { fileName = file.txt, filePath = c:\files }

[333fred]

With C# 10 using a custom interpolated string handler and CallerArgumentExpression, you can get reasonably close by creating something like InterpolatedStringDebug.WriteLine($"{myfile.FullPath}, {myfile.Length}"). Personally, I don't think that this use case is important enough to add more deeply into the language.