Bad closure variable with scoped destruction

[dlangBugzillaToGithub]

Kenji Hara (@9rnsr) reported this on 2013-10-29T21:32:40Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=11382

CC List

• Ali Cehreli
• deadalnix
• Maxim Fomin

Description

In the following code, compiler should reject the function 'foo' by
"has scoped destruction, cannot build closure" error.

struct S
{
    ~this() {}
}

auto foo()
{
    S s = S();
    return { s = S(); };
}

void main() {}

It is checked in toir.c FuncDeclaration::buildClosure(), however currently it doesn't work for the variables which are explicitly declared on statement.

[dlangBugzillaToGithub]

k.hara.pg commented on 2013-10-29T21:33:06Z

Related discussion: http://forum.dlang.org/thread/wsketyuhrbwiaetfbfww@forum.dlang.org

[dlangBugzillaToGithub]

maxim commented on 2013-10-30T05:48:08Z

I think this may break some code but I am not sure about that. 

What is more important is that conclusion in relevant threads was just not to place dtor invocation in the end of function scope because stack struct touched by closure is essentially object residing in the heap, and structs allocated in the heap typically have no dtor call (unless they are wrapped into class or some trick is used). Your proposal to reject code comes from nowhere and it is unnecessary restrictive and does not fit into current practice: allocating structs via new is allowed.

I think right solution is those raised into the thread: just disable dtor invocation in the end of the function scope. Probably some temporal warning will be needed.

In any case, except of struct touched by closure scenario, there are additional cases which should be fixed: nested function and nested structs.

[dlangBugzillaToGithub]

acehreli commented on 2013-10-30T14:16:37Z

The rest of the discussion:

  http://forum.dlang.org/post/l4osr0$2f3q$1@digitalmars.com

Ali

[dlangBugzillaToGithub]

deadalnix commented on 2013-11-05T16:04:10Z

I used to think that the destruction should be triggered by the GC when deallocating, but Kenji is right, this should be an error, or RAII will become quite unreliable.