On Fri, 22 Sep 2017 16:40:35 -0700, [email protected] wrote:
>
> We've had a native 'str' type for a while, and still have one even
> though NativeCall decided to go with Str and 'is encoded'.
>
It's not native in the sense of same sense that NativeCall uses the word.
> Currently it seems to just be a Str under the hood which has very
> few restrictions, other than not allowing binding to a Str.
>
That's the wrong way around. A Str boxes a str under the hood, much like Num
boxes a num.
> What exactly is a 'str'? Is it null terminated or does it know
> its length? Does it have an encoding?
>
Str uses the P6opaque representation. It's defined as something like:
class Str {
has str $!value;
...
}
This means it can support things like mixins. The `str` instance is what
actually holds the string data buffer. It is always in NFG. Its representation
is implementation-defined, but no implementation that provides it supports
mixing in to it, which a high-level type like Str should support.
So, much like num is an unboxed Num, str is an unboxed Str. It's used quite a
bit inside of Rakudo, as it's what all the nqp:: ops for str use. However,
there are user-level places one might wish to have it if dealing with a large
number of strings. For example:
my str @loads-of-strings;
Will be far more compact in memory than:
my Str @loads-of-strings;
Since the latter stores a Scalar pointing to Str pointing to str, while the
former is just a bunch of str.
> Roast indicates it knows how to take an assignment from a Str literal
> (but no literal is used that pushes any boundaries) and
> can be used in multi-dispatch and... that's really about all.
>
I'm sure there's room for more tests, though given that it's on the inside of
every Str, then its functionality is largely covered implicitly (and any method
call on a str will box it to the Str object type to actually call the method).
