const debacle

[Jarrod]

On Fri, 21 Mar 2008 14:15:10 -0400, Steven Schveighoffer wrote:

> In any case, the crux of the problem is still there.  For the version
> with just T, the compiler is not guaranteeing that func doesn't modify
> the input.
> 
> -Steve

One of the biggest reasons for const in the first place was to have this 
type of guarantee available.. And now, you can't even use it properly?

I've always thought that using const function parameters was about making 
a contract that exists solely for the scope of that function.. Basically, 
const in the parameter would assure you that the function would not 
modify the data you pass it. The contract should not exist after the 
scope is left.

I do understand the problem behind this: you can pass a const array to a 
function that takes const and then get a mutable reference to the data 
returned, which is bad. But at the same time I think it's worse how it 
currently is.

I know everyone is throwing in some kind of template or overload idea, 
but mine is a little more simple: Change 'in'. Use 'in' to define a 
function that will take a value and not change it, but make no guarantees 
about the return type (it makes sense too. 'in' should pertain to inside 
the function only). So if you want your function to take a const 
reference and not change the data, use "const in" or just "const". That 
way you can make an overload or a template for each type, and guarantee 
for all three functions that you will not change the data inside the 
function.