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
