3 ms·

This doesn't help with unused variables, which comes up just as often when doing the same thing (coding piecemeal, testing if it compiles, etc.)

Laremere 11y ago
var x int _ = x Mildly annoying, but it avoids unused variables in any code which compiles, and is a helpful reminder of "I was going to do something with this value".
- tatterdemalion 11y ago
  It seems like a warning only lint would be less annoying and a better reminder.
  - sukilot 11y ago
    It is an established fact that humans cannot be trusted to handle warnings responsibly.
    - anon1385 11y ago
      Judging from this thread Go users are regularly using various tricks and hacks to avoid the compiler errors. So evidently Go programmers can't be trusted to handle compiler errors responsibly and not use hacks to hide them. In which case, what is the point of making in an error? It just makes things more difficult for the responsible programmers who don't ignore warnings (instead of a warning that they will notice they have to find and remove an obscure line of code). It was an interesting experiment to make these things errors only, but it's clear that it has failed.
    - im3w1l 11y ago
      I wonder if we can fix the "warnings ui" somehow, so that they work better. The fundamental tension seems to be that programmer thinks he knows what he is doing, adds a warning override and the warning goes away. But then it may turn out that he didn't and the warning indicated a real problem. The problem is the S/N of warnings. Our programmer removed a warning so that real warnings wouldn't drown in a see of false warnings. The question is then, can we have our cake and eat it too? We don't want to completely forget about low risk warnings, we just almost completely. Maybe we could have some kind of exponential backoff when you ignore warnings?
- cpuguy83 11y ago
  Why not use a comment?

Laremere 11y ago

var x int _ = x Mildly annoying, but it avoids unused variables in any code which compiles, and is a helpful reminder of "I was going to do something with this value".

tatterdemalion 11y ago
It seems like a warning only lint would be less annoying and a better reminder.
- sukilot 11y ago
  It is an established fact that humans cannot be trusted to handle warnings responsibly.
  - anon1385 11y ago
    Judging from this thread Go users are regularly using various tricks and hacks to avoid the compiler errors. So evidently Go programmers can't be trusted to handle compiler errors responsibly and not use hacks to hide them. In which case, what is the point of making in an error? It just makes things more difficult for the responsible programmers who don't ignore warnings (instead of a warning that they will notice they have to find and remove an obscure line of code). It was an interesting experiment to make these things errors only, but it's clear that it has failed.
  - im3w1l 11y ago
    I wonder if we can fix the "warnings ui" somehow, so that they work better. The fundamental tension seems to be that programmer thinks he knows what he is doing, adds a warning override and the warning goes away. But then it may turn out that he didn't and the warning indicated a real problem. The problem is the S/N of warnings. Our programmer removed a warning so that real warnings wouldn't drown in a see of false warnings. The question is then, can we have our cake and eat it too? We don't want to completely forget about low risk warnings, we just almost completely. Maybe we could have some kind of exponential backoff when you ignore warnings?
cpuguy83 11y ago
Why not use a comment?