4

I can take any function and throw panic("don't") right in the middle of it, not inside any branch or loop (making the remainder of the function "dead" code), and the go compiler will happily compile and run without reporting that as a problem.

Anyone know if this is by design? (The compiler loudly complains about unused imports, so why not dead code...) They can't go back now and change that behavior since Go 1 is released and they'd be breaking existing well-formed code. Just wondering if this is an oversight or something intentional. If an oversight I guess it'll have to wait until Go 2 (when they can break stuff).

Brad Peabody
  • 10,917
  • 9
  • 44
  • 63
  • 2
    Some discussion on this: https://groups.google.com/forum/#!topic/golang-nuts/D-mmT10VBEA – Intermernet Oct 01 '13 at 03:54
  • 5
    @Kevin You mean "go vet", makes sense. (compare "go vert" http://www.urbandictionary.com/define.php?term=Go%20Vert) – Brad Peabody Oct 01 '13 at 05:06
  • 2
    Dead code is not really a big issue, most of the time it does not indicate a bug like an unused variable which is unused because it got accidentally redeclared. A `panic` or a `return` is easy to spot. Dead code increases binary size a bit but is much less problematic than an unused import. So: Why bother with elaborate dead code detection (which might not catch every piece of dead code) and slow down the compilation? – Volker Oct 01 '13 at 08:58

2 Answers2

2

Short answer: Nobody really gives a rat's ass.

Longer answer:

As @Volker points out, it doesn't make a big difference.

My question was specifically if this behavior is by design. (It's probably a bad question for SO, but oh well.) Was looking to see if this was something that was intentional, or just an oversight.

Java and other languages do it so I was trying to see if there was some "no we don't do that in Go because...". Doesn't seem to be the case. From what I can gather it just wasn't an important enough issue to spend time on putting in.

I asked about this here as well, and the reply was basically that yes, this is expected, sorry you don't like it, it ain't going to change. It's been added to go vet and that should suffice. Which is fine - I agree.

Brad Peabody
  • 10,917
  • 9
  • 44
  • 63
0

Actually, this just exposes bad compiler design, because the control flow should end at the panic. Thus, the compiler should not even be able to translate code after a panic on the same control flow path. Not even a return. If they claim that this is intentional, than they completely lost hold on their compiler architecture. This is a compiler bug, not a language change.

Timm Felden
  • 23
  • 5
  • Right, but the point is they cannot change the behavior of the compiler without breaking the Go compatibility promise. So while I agree on principle, the basic point is that even though the compiler has had major overhauls and I'm sure they could implement this now, it would break older programs, which is why it was just move to Go vet. It's basically a legacy behavior that we're stuck with because it wasn't in the original Go language design. – Brad Peabody Feb 24 '23 at 22:14
  • There are similar issues in other languages and it is fine to deprecate such obvious errors over five to ten years. Btw. my point is actually, that it is a lot harder to build a compiler that can accept such code. – Timm Felden Feb 27 '23 at 07:04