inout and opApply

[Steven Schveighoffer via Digitalmars-d]

On 6/23/16 3:20 PM, Timon Gehr wrote:
> On 23.06.2016 14:58, Steven Schveighoffer wrote:
>> On 6/21/16 5:19 PM, Timon Gehr wrote:
>>
>>>
>>> The problem here is that both variants make sense depending on context
>>> and there is no syntax to distinguish between them. This proposal
>>> interacts in a weird way with IFTI.
>>
>> I know you are probably right, but can you explain maybe via an example
>> what you mean? I'm not understanding your point.
>>
>
> One might legitimately want to pass a inout delegate to some inout
> function and then use the delegate on data with arbitrary mutability
> qualifiers, not just inout.

As you say, we don't have a lot of options. We only have one designation 
for inout, and we must treat it the same no matter where it is.

A possible workaround is to store the inout function pointer/delegate as 
a global variable. I don't like that idea at all, but it would work.

Perhaps we could find a way to mark a function parameter as not being 
part of the inout wrapping, or perhaps mark it as *being* part of the 
inout wrapping (to be backwards compatible). But this is a special thing 
for delegates and function pointers only, since it makes no sense for 
plain parameters.

The more I think about it, the more I think we need to have a clear 
demarcation of when you want the inout-containing delegate to 
participate in the wrapping or not. We can't eliminate existing 
behavior, and without special marking, the rules are going to be ugly 
and unintuitive.

> The IFTI comment was about for example something like this:
>
> struct S{
>     void bar(inout int){}
>     void foo(T)(T arg)inout{
>         // this looks like it can be called with any argument
>         arg(&bar);
>     }
> }
>
> void main(){
>     immutable(S) s;
>     void delegate(void delegate(inout(int))) dg = x=>x(2);
>     s.foo(dg); // today, this works
>     // with the proposed semantics, IFTI deduces
>     // T = void delegate(void delegate(inout(int)))
>     // but then cannot convert dg to a T after
>     // inout resolution
> }

Considering the possible use cases for something like this, I think we 
are better off having this limitation than not being able to use opApply 
with inout.

-Steve