On 9/7/12 2:54 PM, Gareth Smith wrote:
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.
You should be able to create values of @str -- @"Hello world!" works for me. The remaining @~str types are due to legacy code that we haven't ported over yet -- sorry about being slow on that...
Actually, I'm beginning to think that we should overload string literals, so you can write `let x: @str = "Hello world!"` and it should just work.
2. I start off passing a string to a particular function as a &str. But then later I need to change the function so that it saves the string in a structure that the function returns (the structure will then get stored in the task-heap or the unique-heap). 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? I imagine that copying the string is expensive (it may be large), so I change the function to take @str instead of &str. I then have to change all the calling functions to convert their &str to @str and pass it in (but I don't want to do this because it seems just like as many copies will happen), or I change the caller to also take @str instead of &str - and the callers caller, and so on. Then some of my functions take &str and some take @str, depending on their implementation. Maybe this isn't weird. Maybe its good thing. Maybe I am doing it wrong. But to me it feels weird that the implementation leaks. This is not really string specific though to be fair, and I don't see how it can be fixed without ubiquitous global garbage collection.
Yeah :( You're 100% right that this is a bummer. Essentially it's, as you say, the price we pay for not having pervasive GC.
C++ code feels the same pain with the STL types and the various strings that libraries tend to implement; much of the reason we standardized on these "smart pointers" is so that libraries don't write their own string types and exacerbate the problem.
If GC-induced latency isn't critical to you, feel free to write your functions to take @str pervasively. There's no need to feel guilty doing so :) The type is there so that code that isn't micromanaging memory can be written conveniently. As standard library writers, we write everything using &str and ~str because we have to cater to applications that don't want to pay the GC tax, but we definitely don't want everyone to write that way.
The downside of @str is that support for it isn't great in the standard library at the moment, but please feel free to file bugs -- it should be a first-class, convenient, well-supported type.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
