On 11/20/13 10:23 AM, David Piepgrass wrote:
I'm wondering something. Have the Rust developers considered the possibility of using references instead of pointers? It seems to me that this would eliminate a lot of the need for "autoderef". Now I'm not well-equipped to talk about Rust (some of the rules I am totally ignorant about, e.g. I know rust has a "ref" keyword but the tutorial does not mention it) so let me talk about C++ instead. C++, of course, has references, which are exactly like pointers except they are always implicitly dereferenced: int y = 123; int* x1 = &y; // *x1 == y && x1 == &y int& x2 = y; // x2 == y && &x2 == &y In fact, with one small tweak, C++ could have entirely eliminated the need for pointers (except array pointers), and references could have been used for everything except arrays. The reason references cannot replace pointers is that the pointer--the true identity of a reference--is immutable. But that's easily fixable though, by defining &x2 as an lvalue: x1 = &z; &x2 = &z; // Aha! We've changed the pointer inside the reference If the second line were legal, then references could do everything that pointers could do; in that case I think that, for consistency, people would have eventually standardized on using references for everything that doesn't require pointer arithmetic (i.e. arrays). Instead we have this situation where some functions take (non-const) T& and others take T*, so sometimes you have to call functions with "&foo" and other times it's just "foo", and the presence or absence of "&" doesn't signify anything important (for example, it doesn't tell you whether the callee mutates "foo" or not)
This is orthogonal, and I don't want to make that change. I like the explicitness of pointers.
It seems to me that the majority of languages have recognized that references are easier to work with than pointers, and not just because you can write "foo.f()" instead of "foo->f()". That is, I don't think auto-deref (where foo.f() means (*foo).f()) is enough to eliminate the pain of working with pointers instead of references.
This is because in most languages all object types are reference types and they rely on a GC, following Lisp.
Would it help to define ~T, &T and @T as reference types rather than pointer types? I'm sure there are some obvious objections, but perhaps the problems could be ironed out by someone with a better grasp of Rust.
Doesn't work with custom smart pointers.
I'd also like to comment on the removal of "move". While I recognize explicit moves everywhere might be inconvenient, I have noticed that newbies on the list (including myself) are often confused by them. Would a compromise be in order, in which moves are implicit except when passing parameters to methods? I like Bill Byers' suggestion for call-site parameters of the form "move x", "mut x" and just "x" for implicit copy / borrow. Patrick mentioned the annoyance of writing let move x = move foo(move y); but let x = foo(move y); doesn't sound so onerous, and it says something important about foo() that someone reading the code might not realize.
-1. It'd be inconsistent to require it only in parameter position. Patrick _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
