I'll mention one kind-of-key reason why FUNC errors if you don't have a RETURN.
Because returns are definitional functions in each FUNC frame, they can be adapted and dialected. So now you ask: what happens when something just falls out the bottom?
Let's say you write something like this:
foo: func [
return: [integer!]
arg [integer! text! tag!]
][
if integer? arg [
return arg + 1000
]
if text? arg [
return reverse arg
]
arg
]
I imagine you'd expect behavior along these lines:
>> foo 20
== 1020
>> foo "whoops"
** Error: FOO doesn't have RETURN enabled for values of type TEXT!
>> foo <bomb>
** Error: FOO doesn't have RETURN enabled for values of type TAG!
Even though the last value just "falls out" of the function, you presumably don't want that to mean it escapes type checking just because it did.
Mechanically, this is Non-Obvious...
RETURN is not actually supposed to be a "language feature" per se. It's actually a feature of the higher-level generator FUNC...and there are lower-level ways of building functions that lack RETURNs. (If there weren't, how could you write the RETURN function itself?)
Plus it's fully overrideable. You can set RETURN* to some random integer if you feel like it...it's just a variable in the frame. But more frequently you'd like to specialize or adapt it:
bar: function [
return: [integer!]
arg [boolean?]
][
return*: adapt return*/ [value: value + 300]
if true? arg [
return 4
]
720
]
>> bar 'true
== 304
...but here we are at an interesting question. What do you expect to happen with bar 'false ?
>> bar 'false
== 720 ; (A) values falling out of bottom *do not* run RETURN implicitly
>> bar 'false
== 1020 ; (B) values falling out of bottom *do* run RETURN implicitly
Anyway, these kinds of questions are what contributed to the simple rule: If you use FUNC, you have to use the RETURN.
(For the moment though, I'm leaving PROC as returning trash if it falls out the bottom, and it may be that its RETURN should be protected from modification so you can't make it do anything that could be skipped.)