Change to Implict ToString()

[jdub4237]

It would be nice if the language compiler would generate a warning when you used an implicit ToString() on a type that is not a string or derivitave of string and you did not explicitly override ToString() in your type. The warning could be ignored with a pragma or a special character indicate you really meant it like variable.ToString(). This would save numerous software bugs where a type is sent in for a string value either through type converstion or concatenation with a string, and you end up with the Type as the string itself. It's plagued C# software for over 20 years. It seems like this could be a nice language feature.

[HaloFour]

What do you mean "implicit ToString"? Do you have an example?

[jdub4237]

see my comment below

[CyrusNajmabadi]

Requests for the compiler (or just an analyzer in this case) should go to Roslyn or Roslyn-Analyzers.

Do you have an example? That would help direct where this should go. Thanks!

[jdub4237]

see my comment below

[CyrusNajmabadi]

That looks to be a fairly trivial case that an analyzer could be written for if you wanted to warn or block this. Closing out.

[jdub4237]

This is what I am referring to:

byte[] bytes = new byte[] { 0, 1, 2, 3 };

string implicitToString = $"Value equals {bytes}";

Console.WriteLine(implicitToString);

prints

Value equals System.Byte[]

byte[] bytes = new byte[] { 0, 1, 2, 3 };
string explicitConversion = $"Value equals {string.Join(",", bytes)}";

Console.WriteLine(explicitConversion);

prints

Value equals 0,1,2,3

The first is a bug that has happened numerous times in my 20+ year career. Sometimes that would be wanted, that is why I suggest a warning with a pragma or special character to say it's really what you meant to do. How often am I trying to get the type name back as a string versus having to get the values of a string back, but in haste, I don't finish the line of code the way I intended, but the compiler can't let me know I made an error, beause we just implicitly call ToString()? It's often enough.

[jdub4237]

The first is a bug that has happened numerous times in my 20+ year career.

Catching bugs is the primary use case analyzers were created for. This one would be around 20Loc. The actual check is likely 1-2 lines, with the rest just being scaffolding. So if you use the templates here, you'll be 95% of the way along :-)

So I'd recommend just writing this if it's something you routinely run into. It is not likely something we would invest in due to how narrow the issue is, and how possible it is to solve this today.

I'd argue this is a problem that plagues many .NET apps and goes undetected on first pass and has to be addressed with patches later. It would be nice to catch it with the tools we all work with day in and day out. Kind of like nulls, it just took 20+ years for someone to deem it important enough.

[CyrusNajmabadi]

You're the first person to have mentioned this in 20+ years. The issue with nulls has been reported by many orders of magnitude more people, groups and organizations.

I'd argue this is a problem that plagues many .NET apps and goes undetected on first pass

Could you provide any data that backs that up?

It would be nice to catch it with the tools we all work with day in and day out.

Analyzers are those tools. They are a core Roslyn component, and work with the entire ecosystem going back more than 10 years now.

As mentioned above, this is likely just a few lines of code to write an analyzer for. Make a nugget for it, and if others find it valuable, they can use as well :-)

[HaloFour]

Admittedly it would have been nice if .NET had split out ToString into Debug and Display traits that would better convey the intended audience of the formatted text.

[jdub4237]

I think it's probably something that people don't think about because every Object-Oriented language has a ToString() implicit of some sort and going back to Object at the root, ToString() has little use except to reveal the type, which .NET exposes with GetType() too. Many languages did not start with a default of null, so maybe because C#, VB.NET, Java, etc. all did, maybe it that is why folks reported the null behavior more often? I don't know. Changing the null behavior never occurred to me, and now that it has been changed I love it!

A casual Google Search online of "oo languages ToString" revealed in the the top 10 this blog:

https://conscientiousprogrammer.com/blog/2013/12/23/tostring-considered-harmful-part-1/

This Stack Overflow:

https://stackoverflow.com/questions/3319510/java-language-design-with-tostring

and many more links that are relevant. I think this is a relevant thing that developers complain in Stack Overflow or write blogs about and don't reach out to the core language teams to fix. It's just an old relic that needed maybe a couple different methods, maybe ToString() and ToSerial() or something. I can't say I know the answer, just that the problem exists. I've manged dev teams for 20+ years and done my fair share of engineering and I still make the mistake today. It's just easy to do when the tool doesn't tell me about it and let's the code compile. I'll look at writing the analyzer, but there are so many ways it can happen outside of the one example I gave, I think it is a more complicated problem than credit has been given here.,

[CyrusNajmabadi]

I'll look at writing the analyzer, but there are so many ways it can happen outside of the one example I gave

Can you give other examples? It's unclear to me how we would do things differently here than what you would do :)

I think it is a more complicated problem than credit has been given here.,

We'd effectively be writing an analyzer to error on the cases you enumerate. :) So def outline what they would be. We can help you with writing the analyzer.