I can imagine so; But as a counterpoint, isn't it worse with forced implicit returns, where you never have a choice but to return something, and you have to scan the code carefully to see if it was required?
Maybe I'll add a 'noreturn' keyword; single expresions are automatically returned, and you can use a 'noreturn' statement to explicitly return void despite running a non-void expression.
Sadly I don't really have a perfect answer to that. I'm inclined to think making all returns explicit is the right choice, and is only really a problem in a language where long returns are common (specifically in my mind is ruby, where being able to return from the enclosing function is crucial to the common uses of blocks). Arguments against in languages that don't feature this sort of thing seem to be against the length/weight of the word return.
Something I've played with in languages I've worked on is named returns [1], which I like for that case.
[1] https://github.com/stormbrew/channel9/blob/master/sample/c9s... -- see the get function definition, '-> return' names the return 'channel' and 'return <- val' calls it (which returns). Now I might consider having an implicit '<- val' with no lhs that calls the current function's return, I think.
I do think a special case for single statements makes sense, though.
Maybe I'll add a 'noreturn' keyword; single expresions are automatically returned, and you can use a 'noreturn' statement to explicitly return void despite running a non-void expression.