Why compiler allow to put unreachable code after return?

In any function I can put return and any code after it. Even IDE highlight this code as warning and compiler generates ‘Unreachable code’ message - why compiler allow this possibility?

What would be the exact benefit of changing this warning to an error?

I think it have to be less possibilities to write unreachable code). At some moment someone can put wrong return and disable all code after it and doesn’t see warning, and break code logic.
If this possibility introduce some benefits or will introduce in future - it’s ok(just interesting - what kind they are). But if there is no any, even minor, advantages - just why?
This is not a major problem, and if current variant is just a result of current implementation - OK, but I think it’ll be better to prohibit unreachable code after return.

I like Kotlin, but some time ago, when I told about it with my friend - he asked me the same question, and I didn’t find anything to answer. Some people may feel vague misgivings when find useless possibilities when meet them in new language.

I think that if someone puts a “return” statement in the middle of their code, it’s much more likely that they did this intentionally to debug the behavior of the code in a certain scenario, and not accidentally without knowing that this would disable the execution of a part of their code. And if this is indeed accidental, then they will see the warning.

Generally speaking, Kotlin does not report errors for code that has an unambiguous meaning and can be correctly executed. If we believe that the code does not make sense, we may report a warning. However, we do not see any benefit in reporting such code as errors.

3 Likes

If this situation Unreachable code? is still actual - we have two different variants of behavior. In one case this is error, in another this is warning.

Yes, Dmitriy, you are right about warn-severity for code that does not make sense. But my argument is that code after return is potential point for bug. This is answer to your question about benefits of moving to errors.
And from opposite side - I didn’t see any disadvantages when such situation is considered as error by compiler(Java variant).

The behaviour of javac has annoyed me so many times. Luckily javac is so dumb you can work around it by simply writing “if (true) return;”

Putting return statements in the middle of code to debug it is a very common thing to want. It makes no sense to treat it as an error.

4 Likes

But javac behavior saves in such common situation:
if (foo) {
return foo
} else {
-foo = bar
+return bar
}
blabla
blabla
blabla
return foo

And you never write if (true) return not for debugging. if (true) not so harder to write.

Another non obvious place is missing ‘+’ in multiline strings on return. Like:
return “I thought It”
“would be one string”

Unreachable code definetly should not be allowed, this place is very popular bug in other languages. Kotlin already has enough differences with Java. It seems like in the end you want to get absolutely new language so nobody will switch to it like to scala/ceilon/groovy. Please try to be consistent.

P.S. It is the feature that everybody loves in Java.

We’re trying to be consistent in applying this principle: “Generally speaking, Kotlin does not report errors for code that has an unambiguous meaning and can be correctly executed.”

As for “very popular bug” and “feature that everybody loves”, I’ll just say “quotation needed”.

3 Likes