Hacker News Reader

Comment by Abednego | Hacker News Reader

I think you might like Python.

I would argue that automatic inference of 'const' is a very bad idea because it defeats the whole purpose of having 'const' in the first place -- to catch bugs at compile time. If somebody modifies 'find()' in a way that makes it non-const, then your code will continue compiling without errors. However, if somebody relies on the fact that 'count()' is const, then that person would be royally screwed, and it will take weeks to find the bug.

View on HN

I hear you regarding Python.

Re: const inferrence - I have been thinking about it on and off for a while now and I think C++ has it backwards to what it should be. Consider the case when I am implementing some function and need to call foo() passing it variable bar, but don't want foo to modify it.

The way C++ offers to solve this problem is by having me first code a version of foo that swears that it does not touch its argument. So effectively I need to code foo in a way that anticipates const usage, i.e. make it forward compatible with const expectations of external code. Expectations that may or may not materialize, but yet I still need to be mindful of them. This seems excessive.

The way I would rather do it is to state that I expect foo() not to modify my variable when I'm issuing a foo call -

  foo( const bar );  // note the spacious padding :)

and then let the compiler decide if this restriction can be satisfied. Note that this example assumes that bar is a local variable. Another common case is when bar is a given and already a const, and then I can do just this -

  foo( bar );

In other words, const-ness should be a property of just variables. In a vast majority of cases deducing if a function is const can be done automatically -- and this is what I want from my compiler.

Am I missing something? This is a complex subject, so probably I am.

I don't think this is enough for a lot of common cases. Let's say you want to write a 'sort()' function. It takes a 'vector' and a comparator function. Unless that comparator function is declared 'const', you can't be sure that it won't destroy your 'vector'.

Another example. Let's say your 'foo()' function calls 'bar.toString()'. How can the compiler tell whether this call should be allowed when 'bar' is 'const'? You would need to know whether 'toString()' modifies 'bar' or not, but you don't have a way to tell. You might be able to figure this out if you look inside the code of 'toString()', but what if 'toString()' is virtual? You can't look at the code then.

What you're missing is that const is a compile time validation. The compiler _does_ compute whether or not the function you've created is const automatically and uses that to give you an error when it conflicts with what you've told it to expect. This is a way of validating your code's assumptions.

It is slightly annoying that you do need to declare const in functions ahead of time, but it ensures that if you say "this function wont change the variable" your compiler will make sure that you dont. And no amount of changing the internals of that function will change that assertion.

Reply on news.ycombinator.com