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) 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. 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. 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. Everyone's had their fair share of issues with autoref and autoderef, and it's worth considering removing certain portions of it from the compiler. The discussion around this has been rooted in the past, but has recently been brought up as part of https://github.com/mozilla/rust/issues/10504. > The current proposal is to remove all autoref except for function invocations and indexing operations. The method of creating &T from ~T would be `let foo: &T = foo` or `&*foo`. Vectors and strings can't currently benefit from the `&*foo` syntax, but they will hopefully be able to do such once DST lands. In the meantime coercion via type ascription will work and they also have `as_slice` methods. > There are a few reasons backing this proposal: > 1. It's inconsistent to have magical autoref in some places, but not in other places. 2. The camp of "less compiler magic is better" can fly their flag over this change. 3. Code readability does not necessarily benefit from autoref on arguments: > let a = ~Foo; foo(a); // reading this code looks like it moves `a` fn foo(_: &Foo) {} // ah, nevermind, it doesn't move `a`! > let mut a = ~[ ... ]; sort(a); // not only does this not move `a`, but it mutates it! >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
