www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Delegate is left with a destroyed stack object

reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Continuing the conversation from the following thread:

   http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com

(Note: The OP's example there behaves as expected on git head.)

The programmer thinks that the following delegate returned by foo() will 
print S(1) because the delegate uses the local 's' which is supposed to 
live long enough:

import std.stdio;

struct S
{
     int i;
     ~this() { i = 666; }
}

auto foo()
{
     S s = S(1);
     return { writeln(s); } ;  // <-- Uses local s
}

void main()
{
     foo()();
}

However, 's' gets destroyed upon leaving foo() and the delegate is left 
with a destroyed object; so the program prints S(666).

Is that by design or a bug?

Aside: Never mind that the destroyed object gets destroyed again, and 
again, and again. :) (Well, presumably after being copied to other 
object in its dead state, because the address of the object is not the 
same.) (Put a writeln() inside the destructor to see that in action.)

Ali
Oct 29 2013
next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 29 October 2013 at 17:55:45 UTC, Ali Çehreli wrote:

 Continuing the conversation from the following thread:

   http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com

 (Note: The OP's example there behaves as expected on git head.)

 The programmer thinks that the following delegate returned by 
 foo() will print S(1) because the delegate uses the local 's' 
 which is supposed to live long enough:

 import std.stdio;

 struct S
 {
     int i;
     ~this() { i = 666; }
 }

 auto foo()
 {
     S s = S(1);
     return { writeln(s); } ;  // <-- Uses local s
 }

 void main()
 {
     foo()();
 }

 However, 's' gets destroyed upon leaving foo() and the delegate 
 is left with a destroyed object; so the program prints S(666).

 Is that by design or a bug?

 Aside: Never mind that the destroyed object gets destroyed 
 again, and again, and again. :) (Well, presumably after being 
 copied to other object in its dead state, because the address 
 of the object is not the same.) (Put a writeln() inside the 
 destructor to see that in action.)

 Ali


According to the Book of Revelations, 666 is the number of the
Beast (Rev. 13:18), and later (Revelations 19:20) it is stated
that the Beast will be thrown into a lake of fire and brimstone.

That may explain the repeated destruction of s :o)

Whether that is a bug or not, I am unsure.

Craig
Oct 29 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/29/2013 12:02 PM, Craig Dillabaugh wrote:


 the Beast will be thrown into a lake of fire and brimstone.

 That may explain the repeated destruction of s :o)


That's awesome! :)

Ali
Oct 29 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-29 18:55, Ali Çehreli wrote:

 Continuing the conversation from the following thread:

    http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com

 (Note: The OP's example there behaves as expected on git head.)

 The programmer thinks that the following delegate returned by foo() will
 print S(1) because the delegate uses the local 's' which is supposed to
 live long enough:

 import std.stdio;

 struct S
 {
      int i;
      ~this() { i = 666; }
 }

 auto foo()
 {
      S s = S(1);
      return { writeln(s); } ;  // <-- Uses local s
 }

 void main()
 {
      foo()();
 }

 However, 's' gets destroyed upon leaving foo() and the delegate is left
 with a destroyed object; so the program prints S(666).

 Is that by design or a bug?

 Aside: Never mind that the destroyed object gets destroyed again, and
 again, and again. :) (Well, presumably after being copied to other
 object in its dead state, because the address of the object is not the
 same.) (Put a writeln() inside the destructor to see that in action.)

 Ali


Shouldn't "s" be moved to the heap and not destroyed.

-- 
/Jacob Carlborg
Oct 29 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/29/2013 01:23 PM, Jacob Carlborg wrote:


 Shouldn't "s" be moved to the heap and not destroyed.


We are waiting for Walter to say the same thing and Kenji Hara to fix it 
last month. ;)

Ali
Oct 29 2013
prev sibling next sibling parent reply "qznc" <qznc web.de> writes:
On Tuesday, 29 October 2013 at 17:55:45 UTC, Ali Çehreli wrote:

 Continuing the conversation from the following thread:

   http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com

 (Note: The OP's example there behaves as expected on git head.)

 The programmer thinks that the following delegate returned by 
 foo() will print S(1) because the delegate uses the local 's' 
 which is supposed to live long enough:

 import std.stdio;

 struct S
 {
     int i;
     ~this() { i = 666; }
 }

 auto foo()
 {
     S s = S(1);
     return { writeln(s); } ;  // <-- Uses local s
 }

 void main()
 {
     foo()();
 }

 However, 's' gets destroyed upon leaving foo() and the delegate 
 is left with a destroyed object; so the program prints S(666).

 Is that by design or a bug?


Seems reasonable to me.

S s = S(1); // allocates on the stack, because value type, i is 
now 1
{ writeln(s); } // creates closure with reference to stack memory 
"&s"
return ... // returns and destroys local variable s, i is now 666
foo()() // calls closure with reference to invalid memory "&s"

Returning closures with reference to stack memory is a bad idea. 
Maybe  safe should prohibit this?
Oct 29 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
http://dlang.org/function.html


 The stack variables referenced by a nested function are still 
 valid even after the function exits (this is different from D 
 1.0). This is called a closure.
Oct 29 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 29 October 2013 at 21:14:39 UTC, qznc wrote:

 Returning closures with reference to stack memory is a bad 
 idea. Maybe  safe should prohibit this?


According to http://dlang.org/function.html

"The stack variables referenced by a nested function are still 
valid even after the function exits (this is different from D 
1.0). This is called a closure."

It it completely valid to reference that memory. It gets moved 
onto the heap when you create the closure. The problem is that 
the destructor still gets called, so the variable is no longer in 
a valid state post return.
Oct 29 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 29 October 2013 at 21:14:39 UTC, qznc wrote:

 { writeln(s); } // creates closure with reference to stack 
 memory "&s"
 return ... // returns and destroys local variable s, i is now 
 666
 foo()() // calls closure with reference to invalid memory "&s"


That's not how closures work in D – the local variables 
referenced by nested functions/closures will be allocated inside 
the "nested context" for the function, which is placed on the GC 
heap if a reference to it can be escaped. Play around with the 
example some more if you want: Barring any further DMD bugs, you 
are not going to get the contents of i to be corrupted (i.e. set 
to another garbage value).

The problem with the compiler behavior for the code in question 
is that it destructs a live object, and thus clearly breaks the 
type system.

I think the only correct resolution is to not destruct the object 
at the end of foo() – which incidentally also means that the 
destructor will never be invoked, just as for any other 
GC-finalized memory.

David
Oct 29 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/29/2013 02:32 PM, David Nadlinger wrote:


 The problem with the compiler behavior for the code in question is that
 it destructs a live object, and thus clearly breaks the type system.

 I think the only correct resolution is to not destruct the object at the
 end of foo() – which incidentally also means that the destructor will
 never be invoked, just as for any other GC-finalized memory.


To add to that, Maxim Fomin notes in the D.learn forum that there are 
the following conflicting requirements:

1) need to allocate struct into heap due to lambda

2) need to put dtor invocation in the end as usual.

The first one is supported by the closure spec. The second one is the 
well-know struct destruction upon leaving a scope.

Ali
Oct 29 2013
next sibling parent reply Lionello Lunesu <lionello lunesu.remove.com> writes:
On 10/29/13, 22:37, Ali Çehreli wrote:

 To add to that, Maxim Fomin notes in the D.learn forum that there are
 the following conflicting requirements:


So a copy should have been made of the live object, not the destructed 
one. Correct?

Sounds like the destruction and the copy are happening in the wrong order.
Oct 29 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu 
wrote:

 So a copy should have been made of the live object, not the 
 destructed one. Correct?


No. There should only be one struct instance, the one living 
(forever) in the closure context.

David
Oct 29 2013
parent reply Lionello Lunesu <lionello lunesu.remove.com> writes:
On 10/29/13, 22:42, David Nadlinger wrote:

 On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu wrote:

 So a copy should have been made of the live object, not the destructed
 one. Correct?


 No. There should only be one struct instance, the one living (forever)
 in the closure context.

 David


Why? It's a struct. It should be completely fine to create a copy [on 
the heap] for the closure context.

The way I see closure is that any referenced locals become hidden 
arguments. Imagine an implicit ", S s" in the closure's parameter list. 
Everybody would expect 's' (being a value type) to be a copy.

If you want to ensure there's only one instance, you either need to use 
class instead of struct, or allocate 's' on the heap and use a pointer to S.

L.
Oct 30 2013
next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 30 October 2013 at 09:20:40 UTC, Lionello Lunesu 
wrote:

 Why? It's a struct. It should be completely fine to create a 
 copy [on the heap] for the closure context


That's definitely not how D closures work, they always refer to 
local variables "by reference".

One other place where this tends to crop is for code involving 
loop variables, but while the behavior might be unexpected to 
some, discussion has made clear that the code works as intended:

---
void main() {
   import std.stdio;

   void delegate()[] dgs;
   foreach (i; 0 .. 5) dgs ~= { writeln(i); };

   foreach (dg; dgs) dg();
}
---

If structs behaved like you want them to, the snippet would (have 
to) print 0, 1, 2, 3, 4 as well, and tht's definitely too big a 
language change to consider at this stage.

David
Oct 30 2013
next sibling parent Lionello Lunesu <lionello lunesu.remove.com> writes:
On 10/30/13, 10:56, David Nadlinger wrote:

 ---
 void main() {
    import std.stdio;

    void delegate()[] dgs;
    foreach (i; 0 .. 5) dgs ~= { writeln(i); };

    foreach (dg; dgs) dg();
 }
 ---

 If structs behaved like you want them to, the snippet would (have to)
 print 0, 1, 2, 3, 4 as well,


Did NOT know that. Thanks for letting me know :)


 and tht's definitely too big a language change to consider at this stage.


Well, that's a separate issue, whether to change the language or not. 
It's still valuable to discuss unexpected behavior when one runs into it.

L.
Oct 30 2013
prev sibling next sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 30 October 2013 at 09:56:08 UTC, David Nadlinger 
wrote:


 One other place where this tends to crop is for code involving 
 loop variables, but while the behavior might be unexpected to 
 some, discussion has made clear that the code works as intended:

 ---
 void main() {
   import std.stdio;

   void delegate()[] dgs;
   foreach (i; 0 .. 5) dgs ~= { writeln(i); };

   foreach (dg; dgs) dg();
 }
 ---

 If structs behaved like you want them to, the snippet would 
 (have to) print 0, 1, 2, 3, 4 as well, and tht's definitely too 
 big a language change to consider at this stage.

 David


So D managed to mess up closures, too. And that's after years of 
countless complaints about the same issue in JS!
Oct 30 2013
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha wrote:


 So D managed to mess up closures, too. And that's after years 
 of countless complaints about the same issue in JS!


And please no misguided arguments like 
http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx.
Oct 30 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 30 October 2013 at 12:28:13 UTC, Max Samukha wrote:

 On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha 
 wrote:


 So D managed to mess up closures, too. And that's after years 
 of countless complaints about the same issue in JS!


 And please no misguided arguments like 
 http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx.



the loop variable of a foreach will be logically inside the loop, 
and therefore closures will close over a fresh copy of the 
variable each time. The "for" loop will not be changed. We return 
you now to our original article."

Javascript is introducing the let keyword to create properly 
scoped variables. It seems everybody agrees on what should have 
been done.
Oct 30 2013
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 30 Oct 2013 13:28:12 +0100
schrieb "Max Samukha" <maxsamukha gmail.com>:


 On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha wrote:
 

 So D managed to mess up closures, too. And that's after years 
 of countless complaints about the same issue in JS!


 
 And please no misguided arguments like 
 http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx.


Without thinking much about it, why not call loop variables
temporaries that you cannot close over. If you want a closure
you'd have to declare the variable either inside or outside
the loop.

-- 
Marco
Nov 05 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/30/2013 10:56 AM, David Nadlinger wrote:

 On Wednesday, 30 October 2013 at 09:20:40 UTC, Lionello Lunesu wrote:

 Why? It's a struct. It should be completely fine to create a copy [on
 the heap] for the closure context


 That's definitely not how D closures work, they always refer to local
 variables "by reference".

 One other place where this tends to crop is for code involving loop
 variables, but while the behavior might be unexpected to some,
 discussion has made clear that the code works as intended:

 ---
 void main() {
    import std.stdio;

    void delegate()[] dgs;
    foreach (i; 0 .. 5) dgs ~= { writeln(i); };

    foreach (dg; dgs) dg();
 }
 ---

 If structs behaved like you want them to, the snippet would (have to)
 print 0, 1, 2, 3, 4 as well, and tht's definitely too big a language
 change to consider at this stage.

 David


No, the current behaviour is an implementation bug and the expected 
behaviour is indeed to print the numbers from zero to four. The foreach 
iteration variable is stored in loop iteration scope since 2.063. The 
frontend never allocates closures in such a scope even though it is 
required for basic type safety.

Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=2043
Past discussion: 
http://forum.dlang.org/thread/felqszcrbvtrepjtfpul forum.dlang.org

Your example can be changed to use a for loop, and then it indeed 
illustrates your point.

for(int i=0;i<5;i++) dgs ~= { writeln(i); };
foreach (dg; dgs) dg(); // prints 5 five times
Oct 30 2013
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Wednesday, 30 October 2013 at 09:20:40 UTC, Lionello Lunesu 
wrote:

 On 10/29/13, 22:42, David Nadlinger wrote:

 On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu 
 wrote:

 So a copy should have been made of the live object, not the 
 destructed
 one. Correct?


 No. There should only be one struct instance, the one living 
 (forever)
 in the closure context.

 David


 Why? It's a struct. It should be completely fine to create a 
 copy [on the heap] for the closure context.


That would be worse:

void increment(ref int x) { ++x; }

void run(void delegate() f) { f(); }

void main()
{
     int x = 0;
     run( { increment(x); } );
     writeln(x);
}

If the closure took a copy of x then this would write 0. 
Certainly not what I would expect.

I think not running the destructor is the best option (although 
to be honest, I'm not a huge fan of closures to begin with, for 
exactly these sorts of reasons -- they only really work well in a 
pure functional setting).
Oct 30 2013
next sibling parent "Brian Rogoff" <brogoff gmail.com> writes:
On Wednesday, 30 October 2013 at 20:35:14 UTC, Peter Alexander 
wrote:

 I think not running the destructor is the best option (although 
 to be honest, I'm not a huge fan of closures to begin with, for 
 exactly these sorts of reasons -- they only really work well in 
 a pure functional setting).


I disagree. Closures work well in Scheme (more generally, Lisps) 
and ML, which are not purely functional languages. In SICP *, the 
combination of closures and mutable state is used to model OO. I 
used closures more than I used OO in OCaml.

Things are trickier in D for a trickier of reasons. You may be 
right about not running the destructor; I'm still thinking about 
it.

-- Brian

* The Structure and Interpretation of Computer Programs by 
Abelson and Sussman, for those who don't know.
Oct 30 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-30 21:35, Peter Alexander wrote:


 I think not running the destructor is the best option (although to be
 honest, I'm not a huge fan of closures to begin with, for exactly these
 sorts of reasons -- they only really work well in a pure functional
 setting).


I use Ruby all day with a lot of blocks (closures) and I never had any 
problem. In Ruby everything is an object and passed around by reference. 
I guess that's help.

BTW, the default iteration pattern in Ruby is to use blocks:

[1, 2, 3].each { |e| puts e }

Closest translation in D:

[1, 2, 3].each!(e => writeln(e));

But in D one would of course use a foreach loop instead.

-- 
/Jacob Carlborg
Oct 31 2013
next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 31 October 2013 at 07:41:30 UTC, Jacob Carlborg 
wrote:

 But in D one would of course use a foreach loop instead.


I think `std.algorithm.copy` is generally a good replacement for 
foreach loops in functional D code.
Oct 31 2013
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 31 October 2013 at 07:41:30 UTC, Jacob Carlborg 
wrote:

 On 2013-10-30 21:35, Peter Alexander wrote:


 I think not running the destructor is the best option 
 (although to be
 honest, I'm not a huge fan of closures to begin with, for 
 exactly these
 sorts of reasons -- they only really work well in a pure 
 functional
 setting).


 I use Ruby all day with a lot of blocks (closures) and I never 
 had any problem. In Ruby everything is an object and passed 
 around by reference. I guess that's help.

 BTW, the default iteration pattern in Ruby is to use blocks:

 [1, 2, 3].each { |e| puts e }

 Closest translation in D:

 [1, 2, 3].each!(e => writeln(e));

 But in D one would of course use a foreach loop instead.


Those aren't closures, it captures none of the environment. Those 
are just simple lambda functions.
Oct 31 2013
parent "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
On Thursday, 31 October 2013 at 20:56:11 UTC, Peter Alexander 
wrote:

 On Thursday, 31 October 2013 at 07:41:30 UTC, Jacob Carlborg 
 wrote:

 I use Ruby all day with a lot of blocks (closures) and I never 
 had any problem. In Ruby everything is an object and passed 
 around by reference. I guess that's help.

 BTW, the default iteration pattern in Ruby is to use blocks:

 [1, 2, 3].each { |e| puts e }

 Closest translation in D:

 [1, 2, 3].each!(e => writeln(e));

 But in D one would of course use a foreach loop instead.


 Those aren't closures, it captures none of the environment. 
 Those are just simple lambda functions.


Maybe this would be a better Ruby example?


module App
     def self.run
         register_callbacks
         Other.call_all
     end

     def self.register_callbacks
         foo = 10
         Other.register { puts foo }

         Other.register { puts self }

         foo = 20
         Other.register { puts foo }

         foo = 30
     end
end

module Other
       callbacks = []

     def self.register (&blk)
           callbacks << blk
     end

     def self.call_all
           callbacks.each {|cb| cb.call }
     end
end

App.run if __FILE__ == $0


Output is:
30
App
30

-- Chris NS
Nov 02 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 29 October 2013 at 21:37:43 UTC, Ali Çehreli wrote:

 To add to that, Maxim Fomin notes in the D.learn forum that 
 there are the following conflicting requirements:

 1) need to allocate struct into heap due to lambda

 2) need to put dtor invocation in the end as usual.

 The first one is supported by the closure spec. The second one 
 is the well-know struct destruction upon leaving a scope.


Closures follow the infinite lifetime model – the struct scope is 
never left, if you want.

This is not exactly a new scenario, destructors on new'd structs 
aren't called either (unless you manually destroy them).

David
Oct 29 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/29/2013 02:41 PM, David Nadlinger wrote:


 Closures follow the infinite lifetime model – the struct scope is never
 left, if you want.


Agreed but the implicit nature of things is troubling. Imagine that the 
program depends on the destructor to be called:

void foo()
{
     auto s = S(1);
     // ...
}

Later, somebody creates a lambda that silently extends the lifetime of 
the stack frame (apparently, infinitely). That may be very surprising.

Aside: Is it still a closure if the lambda does not refer to the stack 
frame? If so, it is even worse:

import std.stdio;

struct S
{
     int i;
     ~this() { writeln("dtor"); }
}

void bar()
{}

auto foo()
{
     S s = S(1);
     return &bar;    // <-- all is well, this is not a closure
}

void main()
{
     foo()();
}

Imagine someone decides to return a lambda from foo() instead:

auto foo()
{
     S s = S(1);
     return {};    // <-- Should 's' be immortal now?
}

Too subtle for my taste! :)


 This is not exactly a new scenario, destructors on new'd structs aren't
 called either (unless you manually destroy them).


At least in the case of a new'ed structs I have a convenient way to 
destroy them through a pointer. I think in the case of a closure I must 
go through hoops to access or save that pointer.

Ali
Oct 29 2013
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Tuesday, 29 October 2013 at 21:57:25 UTC, Ali Çehreli wrote:

 On 10/29/2013 02:41 PM, David Nadlinger wrote:


 Closures follow the infinite lifetime model – the struct


 scope is never

 left, if you want.


 Agreed but the implicit nature of things is troubling. Imagine 
 that the program depends on the destructor to be called:


It may be confusing but I agree that disabling dtor invocation at 
the end of function scope is a right decision. Technically scope 
is left, but lifetime continues.


 This is not exactly a new scenario, destructors on new'd


 structs aren't

 called either (unless you manually destroy them).


 At least in the case of a new'ed structs I have a convenient 
 way to destroy them through a pointer. I think in the case of a 
 closure I must go through hoops to access or save that pointer.

 Ali


This is not a big deal.

Another but similar case:

import std.stdio;

struct S
{
	int i;
	~this() { writefln("dtor %X, %X", &this, i); }
}

auto foo()
{
	S s = S(1);
	struct SS
	{
		void bar() { s = S(2); }
	}
	return SS();
}

void main()
{
	foo().bar();
	
}

So, one need also to be aware of nested structs (or functions) 
touching local objects.
Oct 29 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-29 22:57, Ali Çehreli wrote:


 Imagine someone decides to return a lambda from foo() instead:

 auto foo()
 {
      S s = S(1);
      return {};    // <-- Should 's' be immortal now?
 }

 Too subtle for my taste! :)


Of course not. "s" is never referred to in the returned delegate.

-- 
/Jacob Carlborg
Oct 30 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 30 October 2013 at 07:49:48 UTC, Jacob Carlborg 
wrote:

 On 2013-10-29 22:57, Ali Çehreli wrote:


 Imagine someone decides to return a lambda from foo() instead:

 auto foo()
 {
     S s = S(1);
     return {};    // <-- Should 's' be immortal now?
 }

 Too subtle for my taste! :)


 Of course not. "s" is never referred to in the returned 
 delegate.


Yes, only variables actually referenced by a nested fiction are 
placed in the nested context.

I agree that the fact that an object's destructor is not run at 
the end of the parent function should ideally be more easily 
visible, but given the inherently implicit nature of D's 
closures, I'm not sure we can do much about that.

David
Oct 30 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/29/2013 10:55 AM, Ali Çehreli wrote:


 Continuing the conversation from the following thread:

    http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com


Kenji Hara added there:

=====
The combination of closure variables + scoped destruction should
be rejected, but currently it isn't. It's a compiler bug.

http://d.puremagic.com/issues/show_bug.cgi?id=11382

Kenji Hara
=====

Ali
Oct 30 2013
parent reply "Xiaoxi" <xiaoxi 163.com> writes:
On Wednesday, 30 October 2013 at 21:15:37 UTC, Ali Çehreli wrote:

 On 10/29/2013 10:55 AM, Ali Çehreli wrote:


 Continuing the conversation from the following thread:

    http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com


 Kenji Hara added there:

 =====
 The combination of closure variables + scoped destruction should
 be rejected, but currently it isn't. It's a compiler bug.

 http://d.puremagic.com/issues/show_bug.cgi?id=11382

 Kenji Hara
 =====

 Ali


kenji is right. compilation error is the only safe approach, if 
you do not wish scoped destruction, don’t request it in the first 
place! dangerous operations like this should be explicit to avoid 
surprises, not hidden in complicared implicit special cases.
Oct 30 2013
next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 31 October 2013 at 00:46:05 UTC, Xiaoxi wrote:

 On Wednesday, 30 October 2013 at 21:15:37 UTC, Ali Çehreli 
 wrote:

 On 10/29/2013 10:55 AM, Ali Çehreli wrote:


 Continuing the conversation from the following thread:

   http://forum.dlang.org/post/l4mi8l$1r1$1 digitalmars.com


 Kenji Hara added there:

 =====
 The combination of closure variables + scoped destruction 
 should
 be rejected, but currently it isn't. It's a compiler bug.

 http://d.puremagic.com/issues/show_bug.cgi?id=11382

 Kenji Hara
 =====

 Ali


 kenji is right. compilation error is the only safe approach, if 
 you do not wish scoped destruction, don’t request it in the 
 first place! dangerous operations like this should be explicit 
 to avoid surprises, not hidden in complicared implicit special 
 cases.


This is wrong in a point that accessing object or not running 
destructor is not safe: closures can touch any object, not only 
structs, making them allocated in heap, and there are many cases 
when struct destructors are not called.
Oct 30 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/31/2013 01:46 AM, Xiaoxi wrote:

 =====
 The combination of closure variables + scoped destruction should
 be rejected, but currently it isn't. It's a compiler bug.

 http://d.puremagic.com/issues/show_bug.cgi?id=11382

 Kenji Hara
 =====

 Ali


 kenji is right.


I think nobody is 'right' here.


 compilation error is the only safe approach, if you do
 not wish scoped destruction, don’t request it in the first place!


Destruction is implicit and it is possible to allocate structs on the 
heap anyway.


 dangerous operations like this should be explicit to avoid surprises,
 not hidden in complicared implicit special cases.


If failing compilation is the way to go, avoiding special cases is not 
why. Erroring out here is a special case.
Oct 31 2013