> All basic types (excluding pointers and references) are const by
default and may be marked 'mutable' to allow them to be changed after
declaration
FWIW, for me, this is an anti-feature, and I would not use this language because of it. The net effect of this would be that I type "mutable" all over the place and get very little for my effort.
I've spent a significant amount of time understanding what the high-consequence programming errors that I make are, and "oops, I mutated that thing that I could have marked const" is a class of error that consumes a vanishingly small amount of my debugging time.
The errors I make that account for a large portion of my debugging time are errors related to semantics of my program. Things that, in C++, are typically only detectable at runtime, but with a better type system could be detected at compile time. The first step for this might be type annotations that specify valid values. For example, being able to annotate whether an argument is or is not allowed to be null, and having that enforced at call sites.
(NOTE: I also don't spend a meaningful amount of time debugging accidental nullptr values, but that's a good first step towards the type annotations I _do_ want)
> The net effect of this would be that I type "mutable" all over the place
You might want to consider adopting a more modern programming style for the benefit of your coworkers (and possibly yourself). Mutability all over the place is a nightmare, speaking as someone who currently has to work in a large codebase written like that. It's hard to predict what value a variable is going to have at any particular point in your code, since instead of only having to check where the variable is defined, you have to audit all the code between the definition and the use. For the same reason, it's hard to guarantee that your invariants are maintained, since there is a much larger surface area to check.
> You might want to consider adopting a more modern programming style
Just because some people think a particular style is useful doesn't mean everyone does. You might want to consider checking your biases before making comments like this. I understand the (many) arguments for using `const`, and I've concluded (for myself) that it's not a useful construct. Read and internalize the rest of my previous comment for more information.
It's not about biases. Using immutability is not just some personal preference. It's common knowledge that mutability everywhere is a bad practice. That's why there's a trend toward immutability by default in newer languages.
You would only type 'mutable' at the handful places that really need to be mutable.
You would also likely delete the 'const' that are already all over the place.
If you really use mutation all over the place, then either you work on something unusual or you should learn to do better.
I never type `const` in the first place. I don't find it useful, which was the point of my original comment.
> then either you work on something unusual
In C++, I've been working on game engines, compilers, interpreters and occasionally some reverse engineering. Not sure if that counts as unusual. I'm always thinking about perf, so if I can safely modify something in-place, I usually do.
> or you should learn to do better
I do just fine without `const`, thank you. Maybe you should learn to have a more open mind.
const can serve to mark invariants in your code as well as provide the compiler with information that it can use for optimizations. I highly recommend Scott Meyers' "Effective C++" wherein Item #3 is to 'Use const whenever possible'.
FWIW, for me, this is an anti-feature, and I would not use this language because of it. The net effect of this would be that I type "mutable" all over the place and get very little for my effort.
I've spent a significant amount of time understanding what the high-consequence programming errors that I make are, and "oops, I mutated that thing that I could have marked const" is a class of error that consumes a vanishingly small amount of my debugging time.
The errors I make that account for a large portion of my debugging time are errors related to semantics of my program. Things that, in C++, are typically only detectable at runtime, but with a better type system could be detected at compile time. The first step for this might be type annotations that specify valid values. For example, being able to annotate whether an argument is or is not allowed to be null, and having that enforced at call sites.
(NOTE: I also don't spend a meaningful amount of time debugging accidental nullptr values, but that's a good first step towards the type annotations I _do_ want)