inout and function/delegate parameters

[Stewart Gordon]

On 05/03/2012 13:49, Steven Schveighoffer wrote:
> On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:
<snip>
>> inout means 'some qualifier but we don't know which one'. The call site on the other
>> hand knows which qualifier it is. If the call is made to work there is no 'making it
>> mutable', because it is mutable all the time. The inout function cannot change the data
>> because it cannot know what the constancy is.
>
> What you would propose is that a delegate which takes a const/mutable/immutable implicitly
> translates to one which takes an inout. I agree it can be made to work, but it does not
> fit into the current definition of inout.

I'm not sure if you understand correctly.  Is isn't a matter of implicit conversion of 
delegates from one type to another, but a matter of (in this case) opApply accepting a 
delegate with a parameter whose constancy matches that of this.

You can think of a function signature with an inout parameter as being really a union of 
three function signatures.

     inout(T)[] func(inout(T)[] param)

is a union of

     T[] func(T[] param)
     immutable(T)[] func(immutable(T)[] param)
     const(T)[] func(const(T)[] param)

In the same way, the essence of what Timon and I are proposing is that we'd be able to 
make opApply's signature a union of

     void opApply(int delegate(ref T) dg)
     void opApply(int delegate(ref immutable(T)) dg) immutable
     void opApply(int delegate(ref const(T)) dg) const

or, to generalise a bit, declare a function whose signature is a union of

     void func(ref T param, int delegate(ref T) dg)
     void func(ref immutable(T) param, int delegate(ref immutable(T)) dg)
     void func(ref const(T) param, int delegate(ref const(T)) dg)

or similarly with pointer or array parameters.

> It would be ideal for inout to solve this, but it's not chartered in such a way to do so.

If I'm not mistaken, inout isn't chartered to do anything particular when it occurs in a 
function signature nested within another.  The spec just leaves it ambiguous.

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

Stewart.