Should (unspaced []) Be VOID (And PRINT Ignore It?)

Development Semantics
1

VETO is now providing a universal "opt-out" behavior, to make nearly any function return NULL based on any of its arguments.

So mechanically speaking, it wouldn't seem there's any great reason for VOID to mean "opt out and return null". It could be reserved for other things.

But there may be ergonomic reasons. Think about patterns like this:

print case [
   ... [...]
   ... [...]
]

If none of the cases match, it would seem rather "cool" if the PRINT was just a no-op. That's awfully clean!

Otherwise you'd have to say:

print cond case [
   ... [...]
   ... [...]
]

But why should you have to? It looks better without.

The argument for not taking VOID and being a no-op would be "preventing accidents". But what counts as an accident?

Let's say you write something like:

print unspaced [thing1 thing2]

And let's say that thing1 and thing2 both turn out to vaporize, so there's nothing to print. If you're looking at code like that, is it bad for that to silently print nothing?

Or even without the UNSPACED, but the normal spaced behavior:

print [thing1 thing2]

Historically I've said that it's best if UNSPACED and SPACED return NULL if they produce nothing. That way, you have to consciously OPT it.

print opt unspaced [thing1 thing2]

If you do that, then I think PRINT outputting nothing makes sense.

Anyway, this ties into the rationale for why UNSPACED returns NULL instead of vaporizing when it produces nothing... and for why PRINT thinks it's safe enough to print nothing if it receives a VOID.

2

I'll mention that this is something of a slippery slope.

Consider functions like APPEND, which have no particular meaning for VOID as the "thing-to-append-to". Let's say you want to "opt-out" of the APPEND operation as a whole, based on the selection of the input. Right now you have to write:

 append cond case [
    ... [...]
    ... [...]
 ] value

Or if you don't like abbreviations:

 append conditional case [
    ... [...]
    ... [...]
 ] value

This gives you the behavior of APPEND's implementation never running, and NULL being the result.

But we could make it so that APPEND received the VOID, and had the same behavior--or perhaps a slightly different behavior--it could return something other than NULL. It could choose anything, like the value (or maybe more sensibly VOID).

append case [
    ... [...]
    ... [...]
] value

This makes APPEND's interface more complicated, and it documents it doing something that doesn't make sense.

I'm skeptical of the value of this. I know it lets you avoid a COND, but I kind of feel like the COND is the price of admission.

So is PRINT different? I'm not sure.

The conservative choice would be to not have a behavior for VOID in these cases, and leave it open for future decisions to be made when there's more information.