On Tue, Feb 04, 2014 at 02:15:39PM -0800, Vadim wrote: > I think that'd be too annoying.
I'm not sure, I suspect it would have very little impact. It would probably simplify the code (always a win) and it would also have some very nice properties. In particular, if you took an `&mut` pointer to a variable, and gave it away, the possessor of that `&mut` pointer could be sure that nobody is even *reading* that data, and hence could be free to mutate it completely in parallel. /me thinks > I'd rather see Rust going the other way, > and permit calling functions which borrow immutably. Clearly you cannot have a mutable and immutable pointer to the same memory. However, it's plausible to permit mutable and *read-only* pointers. We used to have those; we called them `const`. We wound up removing them for a number of reasons. The biggest one is that ensuring memory safety when you are dealing with memory that someone else might mutate is very hard, and thus any code that used const pointers was quite limited in what it could do (in particular you could not create references to the interior of ~ pointers or through enums). The second biggest one is that, for all the pain they brought, const data actually wasn't used that often. Today, I'd suggest that `Cell` or `RefCell` is generally a viable alternative. > In other words, functions could explicitly declare as effect such as > "this function may store in region 'b a reference into region 'a", > (where 'b is the region of the iterator and 'a is the region of the > collection). This seems like a rather different thing -- I don't quite see what the importance or meaning of such an annotation is. Maybe you can elaborate. > Of course, in order to implement futures they way I want them, we'd also > need an effect saying "something in region 'b needs an exclusive access to > region 'a, so please rope it off completely". I don't know why you need this. *If* we made the change I was suggesting earlier, I think we could do quite a nice job with futures using the type system we have today; just have your future take an `&mut` pointer to the data it plans to mutate. This is quite similar to -- but perhaps a generalization of, since it would permit more flexible control flow -- [the proposal I advanced here][1]. Niko [1]: http://smallcultfollowing.com/babysteps/blog/2013/06/11/data-parallelism-in-rust/ _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
