inout and function/delegate parameters

[Steven Schveighoffer]

On Mon, 05 Mar 2012 20:34:09 -0500, Stewart Gordon <smjg_1998 at yahoo.com>  
wrote:

> On 05/03/2012 22:31, Steven Schveighoffer wrote:
>> On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon  
>> <smjg_1998 at yahoo.com> wrote:
>>
>>> On 05/03/2012 13:49, Steven Schveighoffer wrote:
> <snip>
>>>> It's currently transitive, and this would break transitivity. If we  
>>>> want to look at
>>>> fundamentally redefining inout so that it can break transitivity,  
>>>> then we can look at
>>>> that. But I don't think this is a simple "add-on" to the current  
>>>> functionality.
>>> <snip>
>>>
>>> Can you give an example of how it breaks transitivity?
>>
>> Using the above foo function:
>
> Which has only one level of indirection.  So I can't see how  
> transitivity comes into play.
>
>> void main()
>> {
>> void bar(int *x) {*x = 5;}
>> int i = 2;
>> foo(&i, &bar); // this sets i to 5 via the inout reference we pass into  
>> it.
>> }
> <snip>
>
> The foo function doesn't set i.  The bar function does.

The issue is that the bar function modifies i via the inout parameter to  
foo.  That is, bar does not modify i directly, but modifies foo's  
parameter.

>
> The design of inout is that the function with inout parameters doesn't  
> know or care about the constancy of its arguments, _therefore_ cannot  
> modify the data.  The function that is passed in as a delegate, OTOH,  
> _does_ know the constancy of its argument, and so _can_ modify it if the  
> constancy permits.  This is necessary to support foreach in the way  
> we're talking about.

I think maybe transitivity is not the right term.  It's just a straight  
const violation.

The thing I'm getting at is, there are two pieces to inout -- one is, it  
passes the constancy of the parameters back through the return value.  The  
second is it acts as a surrogate for const in terms of API guarantees.   
That means, if I pass in a parameter as an inout parameter, it will not be  
modified during the function execution *through that parameter*.

Again, I want to stress that I think the idea is sound and could be  
implemented.  But I think it fundamentally changes the way inout is  
conceptually designed.

-Steve