3 ms·

const by default: I think I explained badly or you read too much into it or both. This is pure syntactic sugar I'm talking about. Instead of marking const membe

by harry8 7y ago

const by default: I think I explained badly or you read too much into it or both. This is pure syntactic sugar I'm talking about. Instead of marking const member functions const, you mark functions which aren't const "mutable." Literally no change to the semantics of the language, just which one is assumed if you leave it blank. Right now it's mutable by default if you do nothing, it could just as easily have been const, you need to be able to tell the compiler which one you mean with a keyword whichever one is chosen to be represented by no token. If "everything should be const unless it has to be mutable" is a reasonable position to take - which many seem to, then it should be the default, right? Too late for that now. (<star>a) + (<star>b) yeah it's reasonable use. I can't say I care much. Obviously need references for the return value of an operator overload too if you're having operator overloading. It's reasonable. Doesn't thrill me, people have different taste on it which is reasonable too.. IMHO if the answer is "IDE" that's a workaround to a language issue and it may not be a big language issue either but it exists. C++ and Java both have some of that. Is the function taking the arg by mutable reference because Dave forgot? Or was did he have constication hell and a deadline so applied prune juice liberally? Or is it an output? Documentation in the header, popped up by your ide/text editor? sure, but that's also a workaround for something that would be nice if it were clear just by looking.

kllrnohj 7y ago
mutable already exists and means something different from non-const. class foo { void b1(); void b2() const; void b3() mutable; } b1, b2, and b3 are all distinct.
- harry8 7y ago
  Distinct indeed, they've got different names. If they're all called b1() then what? But you're hung up on "mutable" as a keyword. What is the semantics of b1(). The language could make them const semantics instead and so also provide a different keyword for 'non-const' maybe 'nonconst' would do if it really clashes with 'mutable' (I don't care if it is, I'm not proposing this to the committee as it's insane to be incompatible with existing code). When it was all just a twinkle in Bjarne's eye, he could have gone that way. Should have, say I.
zvrba 7y ago
> If "everything should be const unless it has to be mutable" is a reasonable position to take For a language like C++ I don't think that's a reasonable position. "Good" class design is about a class encapsulating some behavior and providing methods to access that behavior. Any "interesting" behavior is based on mutable state, whereas const methods are useful only as observers of the state. So "const" as default would make the code more cluttered... Heck, Java and C# don't even have const (though recent version of C# have added kind-of struct constness...) > sure, but that's also a workaround for something that would be nice if it were clear just by looking. In any sufficiently large program, nothing is clear just by looking. Such "local artifacts@ (like, explicit address-of operator) are irrelevant, the fewer the better. Writing `unique_lock<mutex> lk(&my_mutex)` would not add the tiniest bit of clarity compared to what you write now `unique_lock<mutex> lk(my_mutex)` > Is the function taking the arg by mutable reference because Dave forgot? That's easy to check: change it to const and see whether the method still compiles. > Documentation in the header, popped up by your ide/text editor? In the end, you always have to go to the function's definition and inspect it, and possibly follow the call chain further to find out what's really happening (i.e., the top-level call site is no longer relevant), and that's where IDEs shine. And no amount of syntax changes is going to save you from a const reference being aliased by a non-const one.
- harry8 7y ago
  We're just going to have to agree to disagree on that. Const by default would have saved me quite a few headaches over the years and C++ syntax is the definition of cluttered. Good C++ code has the majority of function parameters marked const. A non const reference member function parameter is usually a warning to look carefully, isn't it? "Everything should be made const in your code unless it can't be" is advice metered out by the likes of John Carmack, Scott Myers etc. so it's pretty popular and oft repeated. The prevailing C++ zeitgeist perhaps. Could still be wrong, absolutely, don't stop thinking there by any means. Constification of a codebase can be a major pain in the butt.

by harry8 7y ago

kllrnohj 7y ago

mutable already exists and means something different from non-const. class foo { void b1(); void b2() const; void b3() mutable; } b1, b2, and b3 are all distinct.

harry8 7y ago
Distinct indeed, they've got different names. If they're all called b1() then what? But you're hung up on "mutable" as a keyword. What is the semantics of b1(). The language could make them const semantics instead and so also provide a different keyword for 'non-const' maybe 'nonconst' would do if it really clashes with 'mutable' (I don't care if it is, I'm not proposing this to the committee as it's insane to be incompatible with existing code). When it was all just a twinkle in Bjarne's eye, he could have gone that way. Should have, say I.

zvrba 7y ago

> If "everything should be const unless it has to be mutable" is a reasonable position to take For a language like C++ I don't think that's a reasonable position. "Good" class design is about a class encapsulating some behavior and providing methods to access that behavior. Any "interesting" behavior is based on mutable state, whereas const methods are useful only as observers of the state. So "const" as default would make the code more cluttered... Heck, Java and C# don't even have const (though recent version of C# have added kind-of struct constness...) > sure, but that's also a workaround for something that would be nice if it were clear just by looking. In any sufficiently large program, nothing is clear just by looking. Such "local artifacts@ (like, explicit address-of operator) are irrelevant, the fewer the better. Writing `unique_lock<mutex> lk(&my_mutex)` would not add the tiniest bit of clarity compared to what you write now `unique_lock<mutex> lk(my_mutex)` > Is the function taking the arg by mutable reference because Dave forgot? That's easy to check: change it to const and see whether the method still compiles. > Documentation in the header, popped up by your ide/text editor? In the end, you always have to go to the function's definition and inspect it, and possibly follow the call chain further to find out what's really happening (i.e., the top-level call site is no longer relevant), and that's where IDEs shine. And no amount of syntax changes is going to save you from a const reference being aliased by a non-const one.

harry8 7y ago
We're just going to have to agree to disagree on that. Const by default would have saved me quite a few headaches over the years and C++ syntax is the definition of cluttered. Good C++ code has the majority of function parameters marked const. A non const reference member function parameter is usually a warning to look carefully, isn't it? "Everything should be made const in your code unless it can't be" is advice metered out by the likes of John Carmack, Scott Myers etc. so it's pretty popular and oft repeated. The prevailing C++ zeitgeist perhaps. Could still be wrong, absolutely, don't stop thinking there by any means. Constification of a codebase can be a major pain in the butt.