On 12-09-07 2:54 PM, Gareth Smith wrote:
Here are a couple of things that have confused me:
1. AFAIK you can't actually create values of @str. It seems like only
~str and &str are the blessed string types. Sinful be you if your data
has lifetimes that do not follow a stack discipline. OK, so @~str seems
to be used instead of @str, but it is ugly to keep reading that and
surely it is not efficient.
Oh no, that's purely an artifact of how we did the bulk conversion from
str to ~str. Literally, it was a giant search/replace with all energy
devoted to keeping-the-compiler-working. @str is totally legit.
I have to ask myself if I should copy the string in order to save it, or
should I pass in an @str to avoid copies?
It depends if ownership-sharing is part of the contract the function is
exposing, or an incident of its implementation. If the former -- if the
whole point is to give it something of shared ownership -- then @str
makes sense. Otherwise &str, as the function taking a local copy is
incidental.
We do make programmers think about ownership, lifetime, sharing, and
copying, at least enough to express their intention. Specifically
because the programmer gets hit with ubiquitous penalties
(everything-unique, everything-copied, everything-GC'ed, or similar) if
we try to save them from thinking about it. And then they profile the
program, see it's slower than C++, and go back to using that. We're
aiming to stay close enough to the C++ performance envelope that this
isn't an urge (whatever else may be).
This is not really string specific though to be fair
No, not string-specific at all. Same issue happens all through our
memory model.
how it can be fixed without ubiquitous global garbage collection.
It's not part of our design criteria to fix "having to think about
lifetime, ownership, copies and sharing". That's intentional.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
