@gchiu at one time asked for an "anti-default". Rather than make the decision of whether to overwrite or not based on the content of the variable and only sometimes evaluate the block...always evaluate the block, then decide whether to overwrite or not based on the result of that evaluation.
The name suggested for it was UPDATE:
>> x: <some-tag>
>> x: update if false [<unused-tag>]
>> print x
<some-tag>
>> x: <some-tag>
>> x: update if true [10 + 20]
>> print x
30
This seems very useful to me. While simple conditionals can move assignments into the block of code, e.g. x: if c [v] => if c [x: v], more complex instances might have several points they'd have to selectively do the same assignment:
number-of-variants: update case [
whatever1 [do some stuff, 1020] ; update for this case
whatever2 [do some stuff, void] ; don't update in this case
whatever3 [do some stuff, 304] ; update for this case
] ; don't update if no matches
But what we noticed was that UPDATE has been taken for a somewhat esoteric port action that I don't think anyone is using at the moment.
I'm not totally getting it, as it seems sort of like a WAIT statement, a SYNC, a FLUSH, a FETCH... I dunno. UPDATE seems a strange word to grab when there's this nice other function for it.
It's in use... but the only mentions are internal. It's what native port actors use to "respond to WAKE-UP". The name could be bumped to ON-WAKE-UP.
UPDATE also is used for database manipulation.
TLUAFED as anti DEFAULT.
Or some other creative option, INGEST, TAKE-IN, TRY-ASSIGN
I like WHATEVER too.
I think I like it. Though one thought is that x: might (...) has the problem of it sounding a bit like the thing that might happen or not is the code in the block running, vs the assignment that might happen.
(Writing might x: (...) may make it look a bit more like it's the assignment which might happen, at the cost of making it look like it might assign the block literally. :-/)
I found a 2020 thread where I just repeated this idea...again. In that post I called it PERHAPS. Which I like a bit better as a part of speech than MIGHT.
Eeeeh. No. Seeing the x: (...) looks too much like the assignment is a done deal before MIGHT (or whatever) has a chance to say anything about it.
I should point out that now things like CASE and SWITCH return NULL again, so PERHAPS would either have to consider both VOID and NULL as non-updating states... or you'd have to put MAYBE on nulls.
x: perhaps case [...]
I Want This Function, So PERHAPS It's Time To Just Add It