The following code fails to compile:

void foo (inout int[] arr)
{
    auto dg = {
        foreach (i, e ; arr) {}
    };
    dg();
}

void main ()
{
    auto a = [3, 4, 5];
    foo(a);
}

Error message:

main.d(9): Error: variable main.foo.__lambda1.__aggr1174 inout variables can only be declared inside inout functions
main.d(9): Error: variable main.foo.__lambda1.e inout variables can only be declared inside inout functions

If I remove the delegate everything compiles. Am I doing something wrong?

-- 
/Jacob Carlborg

On 03/28/2013 09:34 AM, Jacob Carlborg wrote:
> The following code fails to compile:
>
> void foo (inout int[] arr)
> {
>      auto dg = {
>          foreach (i, e ; arr) {}
>      };
>      dg();
> }
>
> void main ()
> {
>      auto a = [3, 4, 5];
>      foo(a);
> }
>
> Error message:
>
> main.d(9): Error: variable main.foo.__lambda1.__aggr1174 inout variables
> can only be declared inside inout functions
> main.d(9): Error: variable main.foo.__lambda1.e inout variables can only
> be declared inside inout functions
>
> If I remove the delegate everything compiles. Am I doing something wrong?
>

It is a bug / problem with inout's design.

On Thu, 28 Mar 2013 04:34:36 -0400, Jacob Carlborg <doob@me.com> wrote:

> The following code fails to compile:
>
> void foo (inout int[] arr)
> {
>      auto dg = {
>          foreach (i, e ; arr) {}
>      };
>      dg();
> }
>
> void main ()
> {
>      auto a = [3, 4, 5];
>      foo(a);
> }
>
> Error message:
>
> main.d(9): Error: variable main.foo.__lambda1.__aggr1174 inout variables can only be declared inside inout functions
> main.d(9): Error: variable main.foo.__lambda1.e inout variables can only be declared inside inout functions
>
> If I remove the delegate everything compiles. Am I doing something wrong?
>

Like Timon said, it's a bug in inout design.

I'm not sure what __aggr1174 is, but you can fix the e error by specifying the type for e (or specifying it as const).

I'm assuming the issue is that the compiler is trying to generate a struct to hold the stack data for foo, and struct members cannot be inout.

It is a difficult problem to solve, because inout has two meanings depending on whether it is a parameter/return or a local variable.  At some point, we need to address this, because inout has so much potential, but suffers from some large deficiencies.

-Steve

well, closure is effectively a struct, so its fields should be properly qualified, e.g. as const.

On 2013-03-28 15:16, Steven Schveighoffer wrote:

> Like Timon said, it's a bug in inout design.
>
> I'm not sure what __aggr1174 is, but you can fix the e error by
> specifying the type for e (or specifying it as const).
>
> I'm assuming the issue is that the compiler is trying to generate a
> struct to hold the stack data for foo, and struct members cannot be inout.
>
> It is a difficult problem to solve, because inout has two meanings
> depending on whether it is a parameter/return or a local variable.  At
> some point, we need to address this, because inout has so much
> potential, but suffers from some large deficiencies.

I had to change to a regular for-loop and declare the element as "const":

for (size_t i = 0; i < arr.length; i++)
{
    const e = arr[e];
}

-- 
/Jacob Carlborg

On Thursday, 28 March 2013 at 14:16:27 UTC, Steven Schveighoffer wrote:
> I'm not sure what __aggr1174 is, but you can fix the e error by specifying the type for e (or specifying it as const).
>
> -Steve

This is a foolishness of dmd frontend. It generates names for copies, temporaries, etc. These names are not only visible (a user can receive error messages referring to such names with no idea what are the variables the compiler is talking about) but accessible which allows to do funny nonsense stuff, probably bypassing type system.

http://dpaste.dzfl.pl/15d67a77

Dmd is the only compiler I am aware of which makes visible internal stuff and allows to manipulate it. These names are created almost anywhere where there is parameter passing, temporary, foreach loop, a tuple access, a lambda or a delegate literal and in many other cases. Judging by console dump of this stuff when compiling phobos, I come to conclusion that dmd for ages is able to accept enormous amount of invalid code.

On Thursday, 28 March 2013 at 16:34:47 UTC, Maxim Fomin wrote:
> probably bypassing type system.

try to bypass the type system; we just saw the variables are typechecked.

On Friday, 29 March 2013 at 09:03:11 UTC, Kagamin wrote:
> On Thursday, 28 March 2013 at 16:34:47 UTC, Maxim Fomin wrote:
>> probably bypassing type system.
>
> try to bypass the type system; we just saw the variables are typechecked.

You saw one particular example, the problem is much bigger.

On Friday, 29 March 2013 at 10:37:42 UTC, Maxim Fomin wrote:
> You saw one particular example, the problem is much bigger.

What's problem? Try it.

On Monday, 1 April 2013 at 20:37:34 UTC, Kagamin wrote:
> On Friday, 29 March 2013 at 10:37:42 UTC, Maxim Fomin wrote:
>> You saw one particular example, the problem is much bigger.
>
> What's problem? Try it.

???

What to try?

It seems there is misunderstanding. I point out that dmd generates names for pretty much internal staff and does not protect them, so they can be manipulated which is accepts-invalid. Such manipulation can probably lead to bypassing type system constraints. The fact that one particular example does not allow to do so, does not necessarily means that no one can. "Program testing can be used to show the presence of bugs, but never to show their absence!" Dijkstra.