[Issue 11886] "cannot access frame" error on lambda in lambda

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=11886

John Colvin <john.loughran.colvin at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.loughran.colvin at gmail.
                   |                            |com

--- Comment #4 from John Colvin <john.loughran.colvin at gmail.com> ---
If th(In reply to Kenji Hara from comment #1)
> The change is introduced by fixing bug 9050 (5fb19ce). But it's not a
> regression.
> 
> With old versions, the OP code had been *wrongly* accepted. So it was
> accepts-invalid bug. The error message is intended and reject invalid code
> expectedly.
> 
> ===
> 
> To be things more clear, I'd explain a current limitation.
> 
> Currently, D/dmd does not support nested context inference for indirectly
> instantiated template lambdas. It is known limitation (at least to me).
> For example following case does not work:
> 
> struct Lambda(alias fun)
> {
>     auto opCall(A...)(A args) { return fun(args); } // Line 3
> }
> void main()
> {
>     int n = 10;
>     Lambda!(x => x + n) f;
>     assert(f(1) == 11); // Line 9
> }
> 
> Output:
> test.d(3): Error: function test.main.Lambda!((x) => x +
> n).Lambda.opCall!(int).opCall cannot access frame of function D main
> test.d(9): Error: template instance test.main.Lambda!((x) => x +
> n).Lambda.opCall!(int) error instantiating
> 
> The template lambda x => x + n has context access (reading local variable n
> declared in main).
> But, until Lambda.opCall is instantiated, the 'nestedness' is unknown.
> Therefore compiler won't supply hidden member for Lambda!(x => x + n) struct
> object.
> Finally, f(1) will call `fun` from instantiated opCall method, but it does
> not know the context pointer of main function, so fun(args) makes the error
> "cannot access frame of function D main".
> 
> Because of the limitation, currently it is impossible to create polymorpthic
> lambda by using existing language primitives.
> 
> ===
> 
> The OP code hits the limitation. By the dmd bug, it had been wrongly
> accepted. But currently it is fixed and expectedly rejected.
> 
> So, I'll change this issue to 'enhancement'.

Is this limitation likely to be ever lifted? I come across it quite frequently
and it's often pretty hard/ugly to work around.

--