R3-Alpha re-used the word RETURN as a PARSE keyword. If it was used, it would make the overall PARSE expression evaluate to what you passed it in a GROUP!.
Conflating the word "return" bugged me, because it felt too easy to confuse with a function's return. Of course, other keywords in PARSE were conflated as well - you had to know you were writing parse rules to know what the semantics were. But RETURN felt worse, for some reason.
RETURN Deleted in 2018, Brought Back for UPARSE in 2021
Despite having dropped the R3-Alpha feature, I thought to give it another shot in UPARSE... so see if my opinion about it had changed.
I noticed an annoyance: that seemingly convenient casual usages of it require you to specify END or you may be missing something:
>> uparse [1 2 <gotcha!>] [return collect [some keep integer!]] == [1 2]
So I was (rightfully) skeptical of incorrect uses.
BUT... when I was writing and obsessing over this issue, PARSE wasn't returning the synthesized result of its block. So getting values out of a parse would have to be done with assignments. People would thus be tempted to reach for RETURN even when they intended the match to make it to the end--resulting in mistakes like the above.
But UPARSE Started Returning Rule Results By Default
Once the natural behavior of a rule would be to synthesize out of the block, why would you "reach for RETURN" when it's so obviously cleaner to not use it?
>> parse data [collect [...]] == [...]
People can understand that works, and checks the rules to the end...and that you should be doing that if you want the rules to be checked to the end.
With the clean answer sitting right in front of you for how to avoid a variable... the only time you would use RETURN was when it did what you meant: terminate the parse now, with this result!
So the functionality was deemed to be worth keeping!
But the name... probably shouldn't be "return".