On Wed, Nov 20, 2013 at 11:23:57AM -0700, 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.
I've thought about it, yes. When first designing the system, we were aiming for C-like semantics, which expose the underlying machinery of the computer more clearly. But I've since come to appreciate C++ references as well, though they are the poster child for creating invisible links between caller and callee. It's not entirely clear to me how C++ like references combine with type inference, particularly the H-M-like variant we are using now. In C++, there is no *operator* to create (or dereference) a reference, instead it is driven implicitly by type coercion (the very topic under discussion, in fact). Since C++ has such limited inference, this works out reasonably OK, but in Rust I imagine it'd be more troublesome. For example: let arr = ~[1, 2, 3]; let v = ~[]; v.push(arr[0]); v.push(arr[1]); v.push(arr[2]); I could legally infer the type of `v` to be either `~[int]` or `~[&int]` here, the meaning is very different, and there is no real way for the user to be explicit about the difference other than supplying some type annotations. We're not immune to this. Our own coercions also potentially interact with inference. They are relatively limited, though, and we tend to have explicit operators as well, which helps. [1] Niko [1] See the "interactions with inference" section in my post. :) _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev