1

In C#, when you declare but don't use a built-in class or struct you get a "declared but never used" warning, even if the variable is assigned to, such as in this code:

string myStr;
myStr = "foo";
return;

However you don't get the same warning for a user-defined class or struct:

Bar myBar;
myBar = new Bar();
return;

Why is there no warning in the latter case? If there are side effects to the constructor, you can just say new Bar(); and the only way there would be side effects to the assignment is if the assignment operator is overloaded. However Visual Studio could check for this and issue the warning if the operator isn't overloaded, yet it doesn't. Is there a technical reason why it doesn't do this?

Jez
  • 27,951
  • 32
  • 136
  • 233
  • I think that only applies to value types. – Transcendent Jun 05 '17 at 10:27
  • Assignment operator cant be overloaded, though you could define implicit cast operators. By the way Run time is not compile time. Not all things can be determined in compile time. So dont expect super intelligent suggestions from compiler – M.kazem Akhgary Jun 05 '17 at 10:31
  • Yes, runtime vs compile time is the answer. You have no idea what a class will do at runtime unless you wrote it. The compiler didn't write it - how is it supposed to know you didn't do some funky stuff in the constructor, or that the DI system isn't going to auto-instantiate your type, or that you didn't have a static constructor that needed to be initialised so that `new Blah()` was useful even though the return value wasn't used? – Charleh Jun 05 '17 at 10:35
  • The C# compiler is not capable of looking deeply enough into code that is called indirectly. It does not have an MSIL decompiler nor the smarts to know what MSIL does if it would. It *must* assume that a constructor has useful side-effects beyond just initializing the class object. Even though it shouldn't, but the C# language specification does not demand it. Warnings are only useful if they are 99.9% of the time accurate. This is the kind of job that ought to be done by a static code analyzer. Lots of them around. Their warnings often need to be suppressed :) – Hans Passant Jun 05 '17 at 10:43
  • https://stackoverflow.com/a/10629031/34092 suggests that the warning isn't shown in this case not because it can't be detected, but that it **can** be detected but it annoyed developers excessively. – mjwills Jun 05 '17 at 10:50

1 Answers1

4

Resharper will show the issue - see Value assigned is not used in any execution path - C# .

Code Analysis will also show the issue - https://msdn.microsoft.com/library/ms182278.aspx .

As to why it doesn't show it to you now (without Code Analysis or Resharper), see https://stackoverflow.com/a/10629031/34092 and https://github.com/dotnet/roslyn/issues/15695 (basically it is 'by design').

mjwills
  • 23,389
  • 6
  • 40
  • 63
  • 1
    Heh, great design based on dumb developers being "irritated". – Jez Jun 05 '17 at 10:59
  • To be fair, temporary variables are very helpful for seeing the return values from a function call. The IDE does allow you to get that information in other ways, but a variable does make it super easy. So the tradeoff is reasonable - especially when they provide other ways (e.g. Code Analysis) to enforce it if you really want to. – mjwills Jun 05 '17 at 11:02
  • They are, but it is completely appropriate to issue a warning at that point. You *should* clean up your pointless variable assignments when you've finished debugging, or at least come to commit your code. – Jez Jun 05 '17 at 11:17
  • In many workplaces, it is mandated that warnings are treated as errors. In which case, now you have the person between a rock and a hard place. I need the variable to debug - but now I can't compile the stupid thing! :) (of course, they could disable the warning but that takes time) – mjwills Jun 05 '17 at 11:22