These functions currently take the desired result units as the second argument.
It is very complicated if the length units of the element are bytes, to ask for this length to be recast in characters due to the fragment-of-a-character on the end problem. In some sense there is quotient/remainder here, which means there are multiple operations here, not just one. There is the equivalent of floor (as many characters as fit, then fillByte) ceiling (every byte filled from some character), remainder (how many left over bytes are there). I think this is silly unless we have use cases driving this.
I believe this restriction matches all use-cases I can think of:
Restriction: If the element (first argument) to either valueLength or contentLength has length units of
characters -> can ask for valueLength or contentLength in
any of characters, bytes, or bits
bytes -> can ask for valueLength or contentLength in
bytes or bits
bits -> can only ask for valueLength or contentLength only in
bits.
and it is an SDE otherwise.
This insures that the result of these functions is always well defined.
I understand why there is a box sized in characters and I need to know its size in bytes, but the opposite I can't see a use case for, and it isn't crisply defined even.
Ditto for length in bits. If the box is sized in bytes I might want that in bits (so * 8), but if the box is sized in bits, and I ask for bytes, what do I want if there is a fragment of a byte? ceiling? floor? remainder?