const debacle

[Christopher Wright]

Janice Caron wrote:
> On 24/03/2008, Jarrod <qwerty at ytre.wq> wrote:
>>  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
> 
> I'm going to have to join forces with Walter on this one. It doesn't
> matter what syntax you use to declare function parameters - any such
> declaration, whatever the syntax, /will break const correctness/.

I think your suggestions are fundamentally broken. If I want a contract 
with a method, I shouldn't have to change my representation of my data.

This method should be const-correct by having parameters that are const 
for however long it's running. After that, everything goes back to the 
caller, which has different contracts. The caller can break contracts 
that the callee is bound to because they are different entities with 
different contracts.