Should Refinement Callsites Use VOID-in-NULL-out?

The concept behind NULL is that it's a somewhat-ornery state, that most functions don't take by default. So it helps catch mistakes.

This makes me feel it's a bit haphazard to accept it at callsites:

>> count: null  ; remember to assign this later...
== ~null~  ; anti 

...

>> append:dup [a b c] [d e] count
== [a b c [d e]]

You got the same behavior as append [a b c] [d e], e.g. the refinement was "revoked" by being null.

But you've lost that protection idea. Would it be safer if VOID were what was used?

>> append:dup [a b c] [d e] count
** Error: APPEND expects INTEGER! for its DUP argument, not ~null~

>> append:dup [a b c] [d e] maybe count
== [a b c [d e]]

This strikes me as a bit safer.

I doubt it should be true at the frame-mechanics level:

>> f: make frame! append:dup/
== #[frame! [
    series: ~
    value: ~
    dup: ~
    part: ~null~
    line: ~null~
]]

>> f.series: [a b c]
>> f.value: [d e]
>> f.dup: void

>> eval f
** Error: APPEND requires INTEGER! if its DUP argument supplied

Frame mechanics have finally been fixed up so that typechecking doesn't mutate any fields. So that feels best to me...because otherwise typechecking would have to turn voids into nulls for the call.

Related Issue: NULLs and Normal Arguments

What's been stopping me from changing this is just a general question regarding argument-tampering, and what the "smooth curve" would be from a normal argument to a refinement.

If you define a normal argument as accepting [~null~ integer!] then it doesn't seem right to say that a callsite can't take null. It would have to be another flag, like [<maybe> integer!] which would trigger the void-means-null callsite convention (but null in frame means null).

Right now the <maybe> parameter flag means something bigger than it probably should... it means if that parameter is void at the callsite, the function won't run at all. (I hadn't fully worked this out, but I think that means if it's null in the frame it shouldn't run at all.) The idea is to make the VOID-in-NULL out convention very fast by skipping a function call altogether.

I'm going to have to think a bit more about it...