const debacle

[Christopher Wright]

Janice Caron wrote:
> On 24/03/2008, Christopher Wright <dhasenan at gmail.com> wrote:
>> 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.
> 
> Whoa - hang on here. You're going to have to define "fundamentally
> broken". When Walter says "fundamentally broken" he usually means "not
> const correct". What do you mean?

I mean a lot of people are saying "fundamentally broken" and I want to 
be like the cool people.

Though in this case, you solved a very particular instance of a very 
general problem, introducing a new language construct to do so.

> Though various options have been discussed, and various suggestions
> have been floated, including by me, I am now recommending one, and
> only one, solution, which is for the function to return a pair of
> indeces. This suggestion supercedes any previous suggestions I may
> have made. And I guarantee you that returning a pair of indeces is not
> broken in any respect.

Agreed, but it doesn't solve the problem if I'm not using a list-like 
data structure.

>> If I want a contract
>> with a method, I shouldn't have to change my representation of my data.
> 
> I wasn't aware that I had suggested changing representation of data.

Const data is not mutable data. If I want to call a method with const 
parameters whose return type is based on its input type, then I have to 
make my data const.

>>  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.
> 
> In general, you /cannot/ convert const to mutable in a return
> statement. For example:
> 
>     const(char)[] g = "hello".dup; // A global variable
> 
>     char[] f()
>     {
>         return g; // NOT acceptable
>     }
> 
> We can argue that a slice of an input parameter should be a special
> case, but why bother? It's hard for the compiler to prove, and
> returning indeces instead is trivially easy.

I just want data that I can mutate and functions that can promise not to 
mutate them.

Originally, at the start of this const foray, everyone clamored for all 
function arguments being immutable by default. If we had that, I'm 
absolutely certain that this issue would have been solved several 
revisions ago.