inout and function/delegate parameters

[Timon Gehr]

On 03/07/2012 04:41 PM, Steven Schveighoffer wrote:
> On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
>> ...
>>>
>>> There are two parts to inout, one is that it can be one function called
>>> 3 different ways, the other is that you know it's constant during
>>> function execution. Some people like that second part, even if it
>>> doesn't fully guarantee everything. I.e. there's a reason people use
>>> const in C++ besides it being trendy.
>>>
>>
>> By passing a delegate that changes an inout-matched argument it is
>> made explicit that inout data may change. Technically, none of the
>> existing guarantees are lost, we just add some expressiveness to the
>> type system.
>
> Yes, I understand that it works. I know that it doesn't violate
> technically any const guarantees.
>

Yes, that is not what I was after:

void foo(inout(int)*x, void delegate(inout(int)*) dg)
// both inout's denote the same wildcard
{   dg(x);
}

void main(){
     int x;
     foo(&x, (p){*p=2;}); // this currently cannot be valid code
}

The function call is explicit about that may change the inout parameter. 
There are no guarantees lost. It is the call site who changes the 
parameter. Code that currently has the guarantee that the parameter 
won't change will keep it, because there is no valid code that could 
silently change semantics under the change and does not use some fancy 
introspection.