const debacle

[BCS]

Walter Bright wrote:
> 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.
>>>
> 
> That's how I interpreted it, too.
> 

OK

>> 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.

I see your point but I'm not sure I agree.

It depends on the small print. Is the contract that the function will 
not modify the data or that calling the function will not result in data 
being modified? (I know that's not to clear but I can't think of a 
clearer way to say that)

In the first case there is no problem because the f function does not 
modify the data, the g function does the modification. In the second 
there is a problem. However, unless I'm missing the point of the request 
(a real possibility) this is all moot as what is requested is not that 
the example above be allowed to work but that something like this be 
allowed:

T[] f(return_const T[]);
void g(T[]);

T[] t;
g(f(t));

for this case the contract can be anything /you/ want.