[eximius]

Part of the problem is conceptualizing this as a reference (which, admittedly, it is without optimization).

Instead, this is a borrow which indicates that the callee will not mutate the argument. It makes more sense in this context.

[haberman]

> Part of the problem is conceptualizing this as a reference (which, admittedly, it is without optimization).

Isn't that also the official name of the feature in Rust? Isn't &T in Rust pronounced "reference to T" and "&mut T" pronounced "mutable reference to T"? That is the impression I get from: https://doc.rust-lang.org/book/ch04-02-references-and-borrow...

[steveklabnik]

It is a reference, yes, and without optimization, is a pointer to a value.

Your parent is suggesting to not think of it in such a low-level way, and instead think of it as a permission. In this case, the pointer being optimized away makes more sense, as it’s not really about it being a pointer.

I’m of two minds about it, to be honest.

[wiggler00m]

Thanks for the book! A++ would read again.

https://www.amazon.com/Rust-Programming-Language-Steve-Klabn...

[steveklabnik]

You're welcome!

[cormacrelf]

If you had a Range<BigNum> then it would make a lot of sense. I can’t remember if Range<T>’s constraints on T would support that, though.

[eridius]

AFAIK the only constraint on `Range::contains` is that the `Idx` type conforms to `PartialOrd`. So you could in fact have a `Range<String>` if you so desired.

[pornel]

Rust doesn't have a syntax distinction for passing by reference vs passing by value (which may sound terrible to a C++ programmer, but Rust has no copy constructors, and types are non-copyable by default, so nothing expensive gets copied by surprise). For example, in the C sense, `Box<u8>` is a pointer, and `&str` is a struct passed by value.

Rust is all about ownership, and `&` means "don't free() this".