Ref/mut vs const/mut vs ""/mut

Rust has a bunch of different naming patterns for the opposite of mut:

Where? Mutable Not-Mutable
Borrowing syntax &mut &
Pattern syntax ref mut ref
Collections get_mut() get()
std::io wrappers get_mut() get_ref()
AsRef, ptr dereference as_mut() as_ref()
Slice to a pointer as_mut_ptr() as_ptr()
Deref, Index, Borrow deref_mut() deref()
Array from a reference from_mut() from_ref()
Slice from a pointer from_raw_parts_mut() from_raw_parts()
MaybeUninit assume_init_mut() assume_init_ref()
Raw pointer syntax *mut *const
Raw reference syntax &raw mut &raw const
Raw pointer cast cast_mut() cast_const()
Pin API map_unchecked_mut() map_unchecked()
Also Pin API get_mut() get_ref()
Proposed pin reference syntax &pin mut &pin const

mut vs nothing naming scheme seems to be preferred, except cases where it causes ambiguity due to limitations of the syntax or where the no-suffix names are used for by-value/owned types.

Generally it's mut vs ref for references, and mut vs const for raw pointers.

Use of const for pointer types is understandable given their connection with C, but the const keyword is also used for const fn, which is an increasingly large part of Rust. It has grown beyond simple constants, and can use mutable types now. The standard library doesn't have const_* methods yet, but methods like const_new are already used in the Rust ecosystem for const fn, not *const.

This makes the experimental &pin const an odd one out, because these references are not raw pointers, and are not related to const-eval, but use the mut/const naming scheme. I assume that &pin T, like &raw T was not an option due to syntax backwards compatibility, but it seems to me that the not-mut Pin references should be &pin ref.

9 Likes

I agree with const being a bad opposite of mut; however, ref is only the opposite of mut in cases where the mut is going to be part of a reference anyway, e.g. when as_mut could have been as_ref_mut and not confused anybody. &pin ref Foo reads like &pin &Foo. (We can see & / β€œref” correspondence in the destructuring pattern ref and in types like cell::Ref.)