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?
3 Likes
I strongly oppose churning Rust’s syntax without really good justification. This isn’t enough motivation in my opinion.
6 Likes
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.
3 Likes
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 asmutin Rust. - In Rust
constmeans that it can be handled at compile time, the value being immutable is just a side effect. It is likeconstexprin C++
*const is as exception to this rule, it mix the meaning of const in Rust and C++.
7 Likes
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 *T and *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 PhantomData (i.e. *T is the most relaxed variance when used by itself), and if you want a nullable pointer you just use Option<*T>.
6 Likes
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 .deref operator.
I think 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 ^'a.
1 Like
While 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.
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.