On 07/09/2012 10:02 AM, Gareth Smith wrote:
Firstly I understand you know a lot more about this than I do, and I have read and appreciated everything that you wrote.
Thanks! I appreciate your patience in discussing it.
A substring (AKA slice) would point to the same character data as its parent string, but have different start/end indexes. I believe that the region system would keep a substring's character data alive for as long as its parent lives (right?).
Yes, though you might as well just advance the pointer and subtract the length a bit, make it a 2-word representation. So long as the data is pinned, you don't need to point to the head of the string buffer (indeed, in a read-only data section, often multiple strings get merged together).
Idiomatic usage would be to pass most string parameters as &str.
Right, so this makes it double-indirect to get at the bytes most of the time.
Apart from fixed-length strings, which could perhaps be treated specially, is this a reasonable way to accomplish the objective of making string pointers the same as other pointers (apart from vector pointers, which in are in another kettle of fish).
Well ... it lets you do substrings (as does a 2-word representation, ptr+length), it's just double-indirect most of the time, because you're usually passing around &str. The only way this differs from what we're doing now is that we are currently single-indirect: &str is actually that (ptr,len) pair itself, not a pointer-to-it, which is the closest we can get to full-speed like C.
That's really all we've done: merged the layer of indirection implied-by / described-by a sigil -- necessary for control of allocation, copying and ownership behavior of the underlying buffer -- and the layer-of-indirection necessary for working with variable-sized-thingies in containers that need to be fixed-size (other structures, stack frames, etc.) So we wind up with only one indirection, not two. We didn't think uniformity of representation was sufficient to justify imposing the systemic double-indirection cost, that's all.
In case you're concerned that this makes str (and []) the sole warts on a type system that is otherwise uniform in terms of treating non-sigil'd type names as allocatable, interior-value things, keep in mind that it's not. Traits-as-types (i.e. when used as fn(x:Trait), not as bounds on type parameters) are currently in the same boat as strings used to be a while back (implicitly @), but they're changing so that they can only be represented through sigils; again so that we can gain-back control over allocation (not always have to box, be able to send, handle constants, perform move-on-self, etc). Likewise closures (fn() types) are not really representable as interior values, since they close over an environment (or no environment) in a variety of ways that the sigils control.
Sorry to sound so stubborn on this; again, can you perhaps point to specific awkwardnesses in the current scheme? Maybe we can mitigate the difficulty by changing evaluation / borrowing / constant / pattern-matching rules a touch.
-Gradon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
