4 ms·

>const is not the default While I agree to a point, I also understand the argument against this. In programs, a lot of state needs to be changing. Which means

>const is not the default While I agree to a point, I also understand the argument against this. In programs, a lot of state needs to be changing. Which means you're going to type mut a LOT over the course of a 100k line program. And frankly, that gets tedious really quickly. If you miss a const in C++, no big deal. The program still works. It's mostly a safety net. [with notable exceptions] But if you forget a mut in Rust, the program is not going to work. That's an advantage (you can't write something incorrectly) but it's also tedious, imo. When working on the C++ codebase daily, I occasionally find myself going "Hmm, that could be const/I need const here to use something" and swap it over. But it's fairly rare, and overall less time investment on my end. Frankly, this explains most differences in Rust and C++. Rust is OK with the developer having to do more boilerplate, more verbose code, etc. for the sake of ensuring correctness. C++ assumes the best and goes with it to save some time in the short run. That's neither good nor bad, just preference.

bombela 3y ago
> That's neither good nor bad, just preference. I would argue that one of them giving you a better chance at producing reliable software should go above and beyond the notion of preference.
- Night_Thastus 3y ago
  Something const would catch is rarely the cause of broken software. In my experience, most issues in software are logical and often derived from complex behaviors and interactions, not misuse of syntax.
Measter 3y ago
> While I agree to a point, I also understand the argument against this. In programs, a lot of state needs to be changing. Which means you're going to type mut a LOT over the course of a 100k line program. And frankly, that gets tedious really quickly. It may not be as large a proportion as you think. Doing a quick grep on the rustc compiler source (483k SLoC), there are 5431 matches for "let mut [\w\d_]+ =", and 29520 for "let [\w\d_]+ =". This is, of course, is only simple bindings and misses out on more complex patterns along with if-let and match expressions, but even so, about 84% aren't mut bindings. One of my own codebases (including all its Rust dependencies is about 1.5m SLoC) comes to about 80% not being mut. Ripgrep + dependencies (718k SLoC) is about 77% not mut.
Buttons840 3y ago
> If you miss a const in C++, no big deal. The program still works. It's mostly a safety net. [with notable exceptions] But if you forget a mut in Rust, the program is not going to work. I just can't take your argument seriously. One of your arguments is "the program will still work, with notable exceptions". I'm not persuaded. You say it's a matter of preference, fair enough. I say let's make companies financially liable for the consequences of their preferences and see how this shakes out.
- Night_Thastus 3y ago
  Every language, every rule, every suggestion has exceptions and gotchas. That's just life, and programming in general. I can't think of anything significant off-hand, it was just more to stave off this part from the post: >If you take a parameter by non-const reference, the caller can only use lvalues to call your function. But if you take a parameter by const reference, the caller can use lvalues or rvalues. So some functions, in order to be used in natural ways, must take their parameters by const reference. >I say let's make companies financially liable for the consequences of their preferences and see how this shakes out. This is completely unrelated. It's also a bit of a dangerous road to go down and I'd suggest thinking about it a lot more.
maratc 3y ago
const never really worked with other C++ features[0], so in any big pile of code you're better off not using const. [0] The compiler will gladly pass a non-const pointer to a non-const object to a function that expects a const pointer to a const object; it all "makes sense". However, a compiler will explode when you're trying to pass a non-const vector of non-const objects to a function that expects a const vector of const objects.
- spacechild1 3y ago
  > a function that expects a const vector of const objects. The elements of std::vector cannot be const.

bombela 3y ago

> That's neither good nor bad, just preference. I would argue that one of them giving you a better chance at producing reliable software should go above and beyond the notion of preference.

Night_Thastus 3y ago
Something const would catch is rarely the cause of broken software. In my experience, most issues in software are logical and often derived from complex behaviors and interactions, not misuse of syntax.

Measter 3y ago

> While I agree to a point, I also understand the argument against this. In programs, a lot of state needs to be changing. Which means you're going to type mut a LOT over the course of a 100k line program. And frankly, that gets tedious really quickly. It may not be as large a proportion as you think. Doing a quick grep on the rustc compiler source (483k SLoC), there are 5431 matches for "let mut [\w\d_]+ =", and 29520 for "let [\w\d_]+ =". This is, of course, is only simple bindings and misses out on more complex patterns along with if-let and match expressions, but even so, about 84% aren't mut bindings. One of my own codebases (including all its Rust dependencies is about 1.5m SLoC) comes to about 80% not being mut. Ripgrep + dependencies (718k SLoC) is about 77% not mut.

Buttons840 3y ago

> If you miss a const in C++, no big deal. The program still works. It's mostly a safety net. [with notable exceptions] But if you forget a mut in Rust, the program is not going to work. I just can't take your argument seriously. One of your arguments is "the program will still work, with notable exceptions". I'm not persuaded. You say it's a matter of preference, fair enough. I say let's make companies financially liable for the consequences of their preferences and see how this shakes out.

Night_Thastus 3y ago
Every language, every rule, every suggestion has exceptions and gotchas. That's just life, and programming in general. I can't think of anything significant off-hand, it was just more to stave off this part from the post: >If you take a parameter by non-const reference, the caller can only use lvalues to call your function. But if you take a parameter by const reference, the caller can use lvalues or rvalues. So some functions, in order to be used in natural ways, must take their parameters by const reference. >I say let's make companies financially liable for the consequences of their preferences and see how this shakes out. This is completely unrelated. It's also a bit of a dangerous road to go down and I'd suggest thinking about it a lot more.

maratc 3y ago

const never really worked with other C++ features[0], so in any big pile of code you're better off not using const. [0] The compiler will gladly pass a non-const pointer to a non-const object to a function that expects a const pointer to a const object; it all "makes sense". However, a compiler will explode when you're trying to pass a non-const vector of non-const objects to a function that expects a const vector of const objects.

spacechild1 3y ago
> a function that expects a const vector of const objects. The elements of std::vector cannot be const.