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.
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.