inout and function/delegate parameters

[Timon Gehr]

On 03/08/2012 12:37 PM, Steven Schveighoffer wrote:
> On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 03/07/2012 11:37 PM, Stewart Gordon wrote:
>>> On 07/03/2012 15:41, Steven Schveighoffer wrote:
>>> <snip>
>>>> In fact, I think this is valid D code:
>>>>
>>>> int i;
>>>> const int *pi = &i;
>>>> int *p = cast()pi;
>>>> *p = 5; // legal because I know this points at i, and i is really
>>>> mutable
>>>
>>> cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it
>>> works.
>>>
>>
>> It is not legal code. I did not point it out because it was clear what
>> was meant. cast() only casts away the top level of modifiers. It is
>> perfectly safe except for class objects.
>
> If it's not legal code, then how is implicitly casting away inout during
> function execution legal code? Isn't this the same thing?
>
> -Steve

It is not legal code because the assignment const(int)* to int* does not 
succeed. The other part is up to debate. The specification does not 
define the semantics of casting away const and changing the data.

It is also not the same as with the proposed change to inout. inout 
would not be 'removed' in the function body, it would be 'removed' upon 
inout-matching the parameters. Inout should be able to replace overloads 
on const, therefore I think that is the way it should work on the 
conceptual level.