TRIM on BINARY!

Development Datatypes
#1

What should one expect when trying TRIM on a binary value. I see right off the bat that it doesn't have any effect:

test: #{2046206F0A6F200A20}
equal? test trim copy test

Ah, well—that's too bad. This is at odds with the Rebol 2 function that treats whitespace in binary the same as in text.

Hold on though—it does work with TRIM/WITH:

>> trim/with copy test #{20}  
== #{46206F0A6F200A}

>> trim/with copy test #{200A} 
== #{46206F0A6F}

>> trim/with copy test #{0A20} 
== #{46206F0A6F}

>> trim/all/with copy test #{0A20}
== #{466F6F}

>> trim/head/tail/with copy test #{0A20}
== #{46206F0A6F}

This is all as I'd expect it.

I want to be certain if this is by design—there seems significant deviation on how this works between Rebol 2, Red, Rebol 3 Alpha and Ren-C. To be clear—I like the above behaviour on first glance.

#2

I see a few issues on this score:

#3

This is at odds with the Rebol 2 function that treats whitespace in binary the same as in text.

I think that viewing things through the lens of BINARY! should mean the information not be assumed as text. It's one thing if you do a FIND or PARSE on a BINARY! which is parameterized with TEXT! explicitly...at which point exploiting the fact that text has a binary conversion is one thing. But most operations should not assume you'd want to do text-like things unless you ask.

The word TRIM doesn't seem like "a fundamentally texty word" to me. So whitespace as a default doesn't feel like a good fit. If any default makes sense, it would be #{00}...but I can't tell if that makes more sense than no default. Maybe erroring is better than passing it through, with the option of BLANK! to opt-out?

I'll point out that Brett made TRIM a userspace function, so any design changes can be hammered out without writing C code. It hasn't been looked at in a long time, so review would be good.

#4

I don't see any need to change it, except maybe to throw an error without WITH