A design loophole of this is that nulls at refinement callsites (currently) represent refinement revocation.
e.g. if you are to say:
>> count: null
== ~null~ ; anti
>> append:dup [a b c] [d e] count
== [a b c [d e]]
Then it's as if the :DUP weren't present at all. That seems sensible enough...
...but it would imply that (continue:with null) is a synonym for (continue).
Yet the :WITH is supposed to be a fancy way of saying "pretend I completed the loop body :WITH this value". To pick one example: you're not allowed to have the body of a MAP-EACH end in null:
>> map-each x [1] [null]
** Error: Cannot append ~null~ isotope to collected MAP-EACH block
In practice we want CONTINUE with no :WITH to act as if the loop ended in a void--not as if it ended in a null.
For that outcome in the world of today, that suggests not erroring when the :WITH is null:
>> map-each x [1 2 3] [
if x = 1 [continue]
if x = 2 [continue:with null] ; must be same as plain continue? :-/
if x = 3 [continue:with void] ; seems more synonymous w/plain continue
]
== []
It's a bit unsatisfying to have that :WITH of a null not acting like if the loop body ended in null and erroring.
This makes me wonder if refinements should implement some kind of rule that makes null and void synonymous... or coupled in a way reminiscent of void-in-null-out.
Perhaps even at callsites, the null state would be illegal:
>> count: null
== ~null~ ; anti
>> append:dup [a b c] [d e] count
** Error: Refinements at callsite can't be null, use e.g. MAYBE to get void
>> maybe count
== ~[]~ ; anti (void)
>> append:dup [a b c] [d e] maybe count
== [a b c [d e]]
What it would mean would be you'd remove refinements from the interface using voids and not nulls. It's a decision kind of in line with how removing elements from MAP! is now done with voids.
So refinement revocation is going to be under scrutiny for a while as I look into this.