What's wrong with just a runtime-checked const?

[xs0]

>> Agreed :) It's definitely more flexible, but the question is whether 
>> the cost is low enough for the feature to still be usable, and whether 
>> it's realistically implementable at all.. Note that even if the GC is 
>> modified, and the constness information is stored somewhere 
>> externally, it can take a lot of updating when passing 
>> pointers/references around...
> 
> Yes, and I don't know enough about function calling to know what exactly 
> is possible, etc.

Well, I don't know much about function calling either (well, you put 
some stuff on stack and some on registers, and call the function :). But 
regardless of how it's done, you need to propagate constness information 
whenever you
- assign a variable a new value
- copy the variable (this includes passing parameters to functions and 
getting return values back)


>> And there definitely are cases where each access would require a 
>> check; in a multi-threaded program you can hardly assume anything 
>> about non-local variables, especially that they don't change :)
> 
> I don't see the problem: you pass isConst by value, so there is no way 
> for anything external to alter the const-ness level that that particular 
> function has. How can that cause any problems?

Hmm, since when was constness a property of a function? It's the data 
that is const or not, and one way or another, you need to know the 
constness for each pointer/reference separately.


>>> Obviously there's no need to check isConst before the second 
>>> assignment. And on the issue of the pointer suddenly changing in the 
>>> middle of the function: well, it's actually not an issue, because I 
>>> worked out that it's best for the function to have a local copy of 
>>> the isConst variable, which means no other resources can change it 
>>> (other than a malicious hacker with pointers). This is also 
>>> conceptually right, because it doesn't make sense to give a function 
>>> a certain level of modification access and then change it while it is 
>>> running.
>>
>> That is true only for correct programs ;) Considering how the purpose 
>> is to catch bugs, though, you can't make that assumption...
> 
> Since the programmer shouldn't be able to access the isConst variable, 
> there's no way to change it, so it shouldn't be a problem.

Hmm, now I really think you'd like to achieve constness on a 
per-function-invocation basis.. Are you sure that is what you want and 
that it is useful?

I think it would be a good time you restated your proposal :)


> How important is time/space in a debug/unittest build? Walter said 
> somewhere that unit tests often cause slow-downs to half speeds, so is 
> speed really such an issue then? Similarly, unit tests builds are 3x the 
> size of release builds (on my current test, anyway). Should we really be 
> worried about efficiency concerns in non-release builds given the losses 
> in efficiency we already accept?

Hmm, afaik, unit tests are only run once per execution and don't 
otherwise affect the speed of execution. Their size also depends on the 
size of the code, but keeping runtime constness information would have 
costs depending on the size of _data_, a much bigger problem I think...

And sure, you need to worry about efficiency. Something like a 10% speed 
loss is probably acceptable, but something that will slow your program 
by a factor of 20 is often not acceptable, even in debug builds...


xs0