On 9/29/11 5:46 AM, Marijn Haverbeke wrote:
I still consider using swap to return things an absolute non-solution. Try writing some code in that style. Unless I'm missing some part of the way you want to approach this, it's absolutely dreadful to work with.
If swap is unacceptable, then, as I've said before, we need to completely rethink the way we do concurrency. Even if we come up with some reference-based solution for single-threaded iteration, we're still back to swap for parallel iteration. If parallel iteration is too painful, people won't use it, defeating many use cases of Rust.
My point here is that we need to make swap palatable. Whether we do that through integrating borrowable pointers into the language at a deeper level, or through standard library magic, doesn't matter to me. But just saying "swap is a non-solution" is sweeping a problem under the rug.
Sure, but being a heap-centric language is completely opposed to what we've been doing so far. A language has shouldn't straddle the fence about the style it prefers, or you get a mess. We should either go modern-style (allocate everything except immediates, garbage-collect, use escape analysis to put some allocations on the stack), or C-style (stack is default, go out of our way to provide safe references). Doing both seems bad taste.
I disagree with this dichotomy. There's nothing wrong with having the programmer be explicit about where allocations live; that's part of what makes Rust a systems language. C# has both value types that live on the stack and reference types that live on the heap and are garbage collected. Expand the notion of garbage collection to include reference counting and C++ does too (via shared_ptr and the numerous other reference counted smart pointer templates).
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
