On 07/09/12 18:25, Graydon Hoare wrote:
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.
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.
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.
Thanks
Gareth
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
