On Fri, 22 Sep 2017 16:40:35 -0700, b...@abrij.org 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).