Auto-dereferencing pointers

[Valloric]

Rust is awesome, but I've encountered a wrinkle.

let x: &u8 = &10;
let y = x == '\n' as u8;

This fails to compile because expected &u8 but found u8. Sigh, ok, fine, there's an easy workaround: *x == '\n' as u8.

Now let's look at this:

let x: u8 = 10;
let y = Some((1, &x));
let z = y == Some((1, '\n' as u8));

This fails for the same reason. The workaround is substantially more ugly now: y == Some((1, &('\n' as u8))).

But let's say you want to use assert_eq! instead of using equality directly because you're writing a test:

let x: u8 = 10;
let y = Some((1, &x));
assert_eq!(y, Some((1, &('\n' as u8))));

This just plain doesn't work because borrowed value doesn't live long enough.

And all of this seems very pointless to me. The compiler knows how a &T relates to a T and it knows it's safe to dereference the pointer because this is Rust and not C so why force the user to go through this ceremony (and that is the right word) of manually matching &T with &T and T with T? Why can't the compiler just Do The Right Thing™ here? It has all the information needed to not make my life harder for no reason.

In C and C++, an int* is effectively an Option<&int> (in Rust) because the pointer may be null so it can't be safely dereferenced. But this is Rust; we know the pointer is safe. Why not just deref it for the user? Why force the user to write convoluted code to placate the compiler and for what purpose?

I know Rust loves explicit casts but we should always examine the benefits of asking the user for such a cast. If it increases safety, great. That's what Rust is about. But I just don't see the win here, only a poor user experience for no gain.

[sfackler]

I'm not sure this is a good idea. If this was implemented, it'd be impossible to determine what a line like this is doing without looking at the signature of foo:

x = foo();

[bharrisau]

I think the intention was only to implement for binary operations. T binop &T automatically becomes T binop T by dereferencing one of the values. Feels like it promotes too much lazy.

[milibopp]

It is probably relevant to consider that this suggestion does work for other operators, such as +:

let a = &3i64;
let b = a + 3i64;

Apart from that, comparing two different references with equal values amounts to true:

let a = &3i64;
let b = &3i64;
let c = a == b; // true

So, when &T == &T and T == T do the same thing and &T + T already works, it would be only consistent to have &T == T work. Or the other way around.

[Valloric]

I think the question we should keep in mind is the following:

What benefit do we provide the user by forcing them to always deref pointers by hand?

Now think about that question for a minute. Give it some thought.

I'm not saying there is no benefit, just that I don't see it. The way I see it, we require input (derefing by hand and matching only &T with &T, not T) but don't provide a corresponding return on that input (safety or whatever). This is in contrast to other Rust features that require work from the developer. The borrow checker is a good example: pleasing it is often annoying, but the return on the work is immense (safety from data races etc) and thus totally worth it.

Note that we already auto-deref for method calls. From the tutorial:

let point = &~Point { x: 10.0, y: 20.0 };
println!("{:f}", point.x);

We don't force the user to write (*point).x because that's annoying.

I'm trying to point out that we've already decided to go down the auto-deref route at least in some places, but are holding back on doing it more widely for... I'm not entirely sure what reason. I'm afraid it has a lot to do with familiarity with C and C++ where one always has to deref pointers and we're just overly attached to that because of Stockholm syndrome.

Note that C++ has references that are pointers that can never be null (so the same feature as pointers in Rust[1]) and they are always dereferenced by default.

[1]: Just not implemented as well. Setting a C++ reference to NULL is possible, but provokes undefined behavior so far less safe than the Rust equivalent.

[Valloric]

Now a Rust RFC: rust-lang/rfcs#102