const debacle

Walter Bright newshound1 at digitalmars.com
Sat Mar 22 21:40:43 PDT 2008


BCS wrote:
>> Look at it another way. You want to declare a filter that does not
>> change the input, but can pass it along to another function that will.
>> I
>> suspect this might be a fundamentally broken concept:
>> T[] f(const T[]);
>> void g(T[]);
>> ...
>>
>> T[] t;
>> g(f(t));
>>
>> What's happened here? Although f() promised it wouldn't modify t, it
>> got modified anyway, because f() passed t to g() which modified it.
>> Far from being a weakness in D's const regime, I think the fact that
>> such cannot be implemented without casting away const at some point
>> shows that the const system is sound, and trying to implement such a
>> filter is unsound.
>>
> 
> I think what is being asked for is a function that asserts that it won't 
> change what it is given but, you can do anything with the output that 
> you could do to the input. Inside it would not be allowed to change it's 
> arg but can return it.

That's how I interpreted it, too.

> This should be safe because anything you do the 
> the return value could be done to the argument giving the same end effect.

I don't believe it's safe because, as my example shows, it violates its 
contract with the caller.



More information about the Digitalmars-d mailing list