I have to read and maintain a lot of code (including things like the wild Rebmake), as well as even odd things I've written. I really find that it can be bewildering on a function that has no RETURN: documentation and some weird expression in the last slot to know if that thing is used by any callers.
My opinion here is that having a return-or-not is a big leg up in understanding the reach of a function, and whether you can reorganize it (or add more code to the end) without breaking something.
But as I've outlined in Implicit Execution of Return in Functions, this goes further than just our preferences for readability. Because RETURN is a function itself, we're in different territory...and it's a territory I want people to be able to explore with doing things like hooking the RETURN function and customizing it.
There will be two options:
-
Use LAMBDA. Lambda is known in languages for a construct that does substitution of the results of a parameterized expression and doesn't need RETURN.
-
One feature of lambda is that it does not have RETURN of its own. This makes it useful for block branches and other services inside the context of another function.
-
If you decide at some point you do want a RETURN, you will have to promote your code to a FUNC(TION) and add a RETURN on all paths--including what drops out the bottom.
-
-
Go your own path and define FUNC to RETURN its body as a group:
func: adapt :func [ body: compose [return (as group! body)] ]People should give deep thought to whether the toolbox of definitions they import into every project should override fundamental behaviors. But if you find something is a closely held belief, then do it.