With the old policy known as "BLANK-in, NULL-out", it was desirable to keep you from having to manually write this pattern:
something: function [arg [blank! file!]] [
if blank? arg [return null]
... ; actual code
]
So an annotation with this behavior was needed. What to call it?
-
<nullifies>
-
<revokes>
-
<retracts>
-
If it were Zen it could be
<unask>
or<mu>
(or<无>
) for "unasking a question".
Because something had to be picked, the suboptimal choice of <blank>
has been used for the past 3 years:
something: function [arg [<blank> file!]] [
... ; actual code
]
It did the job, though it would leave anyone unfamiliar scratching their head about what the difference between blank!
and <blank>
was.
Now It's "NULL in...NULL out" (but the call needs TRY)
This is about as exciting a change as we get around here--and frees BLANK! up for more interesting dialecting without getting entangled in this.
What you want to save time writing is now:
something: function [arg [<opt> file!]] [
if null? arg [return raise make error! [id: 'try-if-null-meant]]
... ; actual code
]
(Let's put aside that <opt>
should probably be <null>
.)
One fairly obvious-seeming name for the annotation would be <try>
.
something: function [arg [<try> file!]] [
... ; actual code
]
It's a little bit weird, because it's saying "if someone passes a NULL to to ARG, they're going to have to use TRY SOMETHING"
Although it's a weird connection, it definitely makes the connection. So I'm going to go with it.
Efficiency Note: The Function Isn't Called At All
Something to know about this trick is that it actually is good for performance. The function is bypassed completely--it typechecks the arguments but then the frame is discarded!