Personally, i think these two uses of the "const" keyword is a little misleading. In Rust the "const" keyword is mostly associated with "compile-time evaluation and values", while these two are quite... meaningless. Maybe invent some new syntax for them in the next edition?
I strongly oppose churning Rust’s syntax without really good justification. This isn’t enough motivation in my opinion.
I don't think it's misleading, nor is it meaningless. The syntax simply promises that the pointer itself provides immutable/const access to its pointee, and its syntax and semantics (even though not treated the same as specifying e.g. a local var with let) are pretty close to one another.
In any case, like @mjbshaw said, it'd cause such a ridiculous amount of churn in the ecosystem (especially the parts that deal with FFIs, which can be tricky code at the best of times) that it's immediately obvious that it isn't worth the cost.
While I agree that it would probably be too complex to change this now, I agree that the current syntax is misleading too, because it break the usual assumption that variables are immutable by default in Rust (immutable reference are not
&const), and because
const has not the same meaning in the rest of the language.
Const has not the same meaning in C++ and Rust :
- In C++
constactually means the value is not mutable. It is like the opposite as
- In Rust
constmeans that it can be handled at compile time, the value being immutable is just a side effect. It is like
*const is as exception to this rule, it mix the meaning of
const in Rust and C++.
While I stand by what I said earlier about the cost of changing it, you're right when you point out the asymmetry in the syntax. Something for a future descendant of Rust to fix
I imagine this syntax was chosen to make it explicit that the access is immutable while also explicitly pointing out (pun intended) that it is a raw i.e. dangerous pointer. I also imagine the choice was made before there was a coherent idea within the group of people working on Rust at the time about:
- compile time evaluation (i.e. what
constis mostly used for in Rust, aside from immutable raw pointers)
- The parallels between safe immutable bindings and unsafe immutable raw pointers
IIRC, it was originally
*mut T, but was changed to
*const T and
*mut T sometime pre-1.0 because people were expecting Rust
*T to be C
T *, not
const T * (in a world where casting
const away isn't UB).
If we use
*T, I'd personally want it to be non-null (basically
ptr::NonNull<T>), with variance information handled with
*T is the most relaxed variance when used by itself), and if you want a nullable pointer you just use
const is a low use item. Since
let is a compile-time evaluation when used with literals, you use
const when wanting a reusable identifier that isn't covered by enum.
*T is pretty awful for readability. Personally if starting over would not reuse "multiplication" at all. Pointers aren't generally for safe rust so would maybe pick something in path
ptr::. The other use would be a suffix
Copy gets under my skin more; I may type clone but always thinking that I'm copping the structure.
While on the syntax train (going even further off OP topic but only a small comment.)
I could see
&'a mut being changed to
&mut'a or even have the symbol changed
const is not great in Rust context, it's mostly needed for C pointers, where it can mean exactly what it means in C, so it's not too bad.
And Rust hasn't churned out through the
dyn addition yet. There are still some
try! leftovers, and half of crates is on 2015 edition.