On 04/06/2011 11:40 AM, Niko Matsakis wrote:
Would this crash? If not, why not? I guess it ultimately depends on what kind of ref-counting scheme is in place for strings (which I presume are stored in the heap, despite their value semantics).
No. They're not to be permanently stored in the heap; we'll be supporting strings with partial internal segments (small vector optimization) in the near future. Besides which this kind of transparent copying or refcounting wouldn't work in cases where the copied thing is mutable or has a destructor we expect to run at a particular time (respectively).
In general I want to make a clear statement of preference in this conversation: if the compiler's going to insert side effects to ensure safety of corner cases, I'd quite prefer to be inserting optional failures (with compile-time warnings that it's doing so) than inserting "make it right by fudging the memory semantics" code (extra copies or extra refcounts).
The whole point of all of this machinery is to be predictable to programmers who are spending mental energy to retain awareness of pointer graphs, ownership and memory models. The cognitive cost of "task fails when something I wasn't expecting happens" is already being paid essentially everywhere in rust code; nothing new to think about is arises by adding a failure (though a warning makes sense, as it's more-likely a coding mistake).
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
