C# Compiler Enhancement Suggestion

Question

Imagine someone coding the following:

string s = "SomeString";
s.ToUpper();

We all know that in the example above, the call to the “ToUpper()” method is meaningless because the returned string is not handled at all. But yet, many people make that mistake and spend time trying to troubleshoot what the problem is by asking themselves “Why aren’t the characters on my ‘s’ variable capitalized”????

So wouldn’t it be great if there was an attribute that could be applied to the “ToUpper()” method that would yield a compiler error if the return object is not handled? Something like the following:

[MustHandleReturnValueAttribute]
public string ToUpper()
{
…
}

If order for this code to compile correctly the user would have to handle the return value like this:

string s = "SomeString";
string uppers = s.ToUpper();

I think this would make it crystal clear that you must handle the return value otherwise there is no point on calling that function.

In the case of the string example this may not be a big deal but I can think of other more valid reasons why this would come in handy.

What do you guys think?

Thanks.

Answer 1

I'm having flashbacks to putting (void) casts on all printf() calls because I couldn't get Lint to shut up about the return value being ignored.

That said, it seems like this functionality should be in some code checker tool rather than the compiler itself.

Answer 2

I'd actually prefer a way to flag a struct or class as [Immutable], and have this handled automatically (with a warning) for methods called without using their return values on immutable objects. This could also protect the object by the compiler from changes after creation.

If the object is truly an immutable object, there really would be no way to handle it. It also could potentially be used by compilers to catch other common mistakes.

Tagging the method itself seems less useful to me, though. I agree with most of the other comments regarding that. If the object is mutable, calling a method could have other side-effects, so the above code could be perfectly valid.

Answer 3

If you have Resharper it will highlight things like this for you. Cant recommend resharper highly enough, it has lots of useful IDE additions especially around refactoring.

http://www.jetbrains.com/resharper/

Answer 4

I am not sure that I like this. I have called many a method that returns a value that I choose not to capture. Adding some type of default (the compiler generates a warning when a return value is not handled) just seems wrong to me.

I do agree that something along the suggested lines might help out new programmers but adding an attribute at this point in the game will only affect a very small number of methods relative the the large existing body. That same junior programmer will never get their head around the issue when most of their unhandled return values are not flagged by the compiler.

Might have been nice way back when but the horses are out of the barn.

Answer 5

This doesn't warrant for a warning or pragma. There are too many places where it is intended to discard the result, and I'd be quite annoyed getting a warning/error from the compiler just because the method was decorated with some dodge attribute.

This kind of 'warning' should be annotated in the IDE's Editor, like a small icon on the gutter "Warning: Discarding return value" or similar.

Answer 6

Does one call a method for its side-effects, for its return value, or for both? "Pure" functions (which have no effects and only serve to compute a return value) would be good to annotate as such, both to eliminate the type of error you describe, as well as to enable some potential optimizations/analyses. Maybe in another 5 years we'll see this happen.

(Note that the F# compiler will warn any time you implicitly ignore a return value. The 'ignore' function can be used when you want to explicitly ignore it.)

Answer 7

At least a compiler-warning would be helpful. Perhaps they add something similar for C# 4.0 (Design-By-Contract).