The current behavior of FUNCTION with a <local>
tag is to let you specify explicit locals, while still gathering SET-WORD!s in the body. So a hypothetical example would be:
foo: function [a b <local> c d] [
set [c d] reduce [a b]
x: c + d
return x
]
The example is kind of dumb, because the SET line could have used set [c: d:] ... in this case and gotten locals gathering behavior. In any case, the much more common case is to want to suppress locals gathering for a set-word (<with>
, formerly known as /EXTERN) than to force locals gathering for non-SET-WORD!s.
FWIW, I've never used <local>
with it's current behavior in a FUNCTION. There's also the ability to use SET-WORD! in the spec to specify locals without disabling locals gathering. Plus I don't feel like there's a whole lot of uses of FUNC...where FUNCTION vs. FUNC would make a difference...that don't have a /LOCAL in it.
So what if <local>
meant don't do locals gathering, and FUNC went away. What we're really comparing here is:
function [a b <local> c d]
func [a b <local> c d]
At which point we're talking about a 4 character difference. And people who wanted to could abbreviate FUNC for FUNCTION and still get to say they wanted locals gathering or not in the same length while using FUNC for locals gathering also.
@rgchris has suggested that in cases of functions that are declared inside objects, the ergonomics of having something that doesn't do locals-gathering in order to get at the object fields is important. But I think there's a lot of work to be done there, with a METHOD that can somehow work with our new binding capabilities to avoid functions that have copies of their bodies made on every instance of an object class made. It may change the dynamics of that situation entirely.
In any case, I think it would be pleasing if "FUNC" were not necessary or in the box, so it's worth thinking about.