One of the reasons I said I did not like /ANY on GET and SET is because it didn't seem a good match for OPT-ness. And ANY is a very common construct. So if people get in the habit of naming their refinements /ANY it would be kind of irritating. One doesn't want to set a bad precedent.
But for reasons that have been reasoned to death, SET-WORD! doesn't error on null assignments, it just clears the variable. That's firm now. Re-read the post if you need to.
It thus seems to make sense that SET of a WORD! would do what a SET-WORD! would do, and not error. And GET returning a null seems okay, since most routines don't take NULLs as input. If you really want to check something is not null you can do that on the result...e.g. non null get word.
(Still shopping for a single term for "non null".)
So there'd seem to be no need for a refinement... except...
...something has to be done about VOID!
VOID! assignments still cause errors on SET-WORD!:
>> x: print "still an error"
** Script Error: x: is VOID!
If you want to write truly generic code (like, say, a READ-EVAL-PRINT-LOOP), you want to really accept not just nulls, but also "ANY"-VALUE!...and that counts void.
So we have a situation where:
- This comes up nearly almost never.
- "ANY" actually sort of feels like it is sensible for the behavior you're expanding, since it's no longer talking about non-ANY-VALUE!d NULLs.
Hence I may be willing to bring GET/ANY and SET/ANY back, but under the new meaning applying to #[void].
But still, get/any 'some-unset-var
will answer UNSET? back. Regular GET would have done so too...but what's the harm?
Afterthought...should plain GET-WORD! not get voids?
If SET-WORD! won't set voids, it seems that maybe GET-WORD! shouldn't get them. You really aren't supposed to be using them as values or signals or anything.
I think I'd be comfortable saying you had to use a special function to get a void out of a variable.