It doesn’t ring a bell to me as someone who’s spent a lot of time in the Rust community, so I’d say it’s probably just a difference in personal jargon rather than a Rust versus C thing.
(Rust usually uses “reference” instead of “pointer” anyway.)
Yes, they are – well, as much as raw pointers are. In reality, the optimizer can always remove indirections when it can prove that doing so doesn’t affect visible semantics, but that applies equally to raw pointers and references.
(edit: replaced asterisks with “[asterisk]” since HN’s Markdown has no way to escape them.)
Critically, Rust references have pointer identity: you can convert between references and raw pointers, and if you convert a [asterisk]const u32 to &u32 and back to [asterisk]const u32, the pointers are guaranteed to compare equal. In my opinion this is unfortunate. It would be nice if the compiler could represent &u32 in memory as if it were just u32, i.e. just pass the value rather than a pointer. After all, the pointed-to value is guaranteed to remain unchanged as long as the &u32 exists. And passing by value is almost always faster for small values (where the size of a value <= the size of a pointer); the programmer could just pass by value directly, but only if they know it’s a small value, which isn’t the case in generic code. Unfortunately, the ability to compare pointer identities means that you really do need a pointer, even though most code never does so. (LLVM can transform pointers to values for local variables and even function arguments if it can prove that the actual code never checks pointer identity, but again, that applies to both references and raw pointers; most of the distinction between the two has been lost by the LLVM IR stage anyway.)
It doesn’t ring a bell to me as someone who’s spent a lot of time in the Rust community, so I’d say it’s probably just a difference in personal jargon rather than a Rust versus C thing.
(Rust usually uses “reference” instead of “pointer” anyway.)