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.
Related discussion: http://forum.dlang.org/thread/wsketyuhrbwiaetfbfww@forum.dlang.org
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.
The rest of the discussion: http://forum.dlang.org/post/l4osr0$2f3q$1@digitalmars.com Ali
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.
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18704 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB