> there have been rumblings about dropping this Really? I don’t pay attention to everything that goes on, but keep an ear to the general pulse, and I haven’t h

> there have been rumblings about dropping this Really? I don’t pay attention to everything that goes on, but keep an ear to the general pulse, and I haven’t heard anything even vaguely serious about this since the mutpocalypse back in ¿2014?, which failed (sadly, in my opinion—though I was undecided back then). But I wouldn’t mind dropping immutable local bindings; as you say, it’s low signal and mostly just an annoyance. I’m interested if you have any citation, however loose; I’m curious. —⁂— I think the interesting difference between Rust and C/C++ in this space is the spelling, and just how significant its impact is. There are two parts to this: ① The reading order. C/C++ reading order is a hodge-podge of right to left and left to right. And what’s the difference between `T const * name` and `T * const name`? There’s a fair chance one who doesn’t know and hasn’t developed the appropriate intuition will guess incorrectly. (In pseudo-Rust terms: they’re `mut name: const T` and `const name: mut T`, and I think I got that the right way around.) See the worked example in https://en.wikipedia.org/wiki/Const_(computer_programming)#C++_convention https://en.wikipedia.org/wiki/Const_(computer_programming)#C... for a particularly painful example: `double (*const (fun(int))(double))[10]`. I believe that’s equivalent to `fun: fn(int) -> mut fn(double) -> const mut [double; 10]` in Rust (keeping raw pointers and C++ type names), which is much clearer, reading purely left to right. ② The default for constness. C/C++ default to mutable and require that you spell out any qualifiers (const in one directions, restrict in the opposite, dunno if there are others). Rust goes with a more sound hierarchical model instead, defaulting to immutable (the more restrictive) and requiring that you spell out any functional additions you want (mutability, which actually corresponds more to restrict), and I’m glossing over references versus raw pointers but because of having taken a different foundational design it’s all more sound and sensible to my eyes, with the simplest spelling providing the least privilege, and more keywords adding more privilege. (Raw pointers are spelled const/mut rather than just /mut as with &/&mut, but that’s to avoid confusion or error, given their role in FFI.) It’s an important philosophical difference; C++ templates versus Rust generics exhibit much the same difference. Well, is it any wonder that Rust has kept on surfacing LLVM bugs because noalias wasn’t exercised much in C/C++ code? When you have to add a restrict keyword, especially when the compiler doesn’t help you… Well, the glib summary is that Rust is better in this area, with a better theoretical foundation and lessons learned from the likes of C/C++, but of course it’s more nuanced, and there are some types of architectures that don’t translate well to Rust. But it’s interesting to reflect on the differences. Because Rust basically does const all the things, and makes it easier and safer to do so. Kinda funny that I started the second half of this comment saying the spelling had a particularly significant impact, and ended up back at the memory/pointer/reference model differences. That’s definitely critical, but the spelling is a major part of it too.