• Ramon (18/18) Apr 22 2016 I have something along this way:
• Ramon (8/8) Apr 22 2016 mmm, I figured the problem, but don't know how to solve it.
• ed (6/14) Apr 22 2016 new or make with arg or new or make then opAssign or this(this).
• ag0aep6g (5/11) Apr 22 2016 So the struct is destroyed at the end of DoDirSearch, despite there
• ag0aep6g (3/7) Apr 23 2016 I've filed an issue:

Ramon <midiway midi.rs> writes:

I have something along this way:

struct json_value
{
	..
}

function DoDirSearch(..)
{
	immutable json_value cbk = json_value(prms.argv[3]);
	assert(cbk != json_value.init); // OK, pass
	
	import core.thread;
	new Thread({
		assert(cbk != json_value.init); // FAIL!
	}).start();
}

the problem is, my struct value is not saved in the spawned tread 
context, so this assert fails while at the start it passed:

assert(cbk != json_value.init);

Ramon <midiway midi.rs> writes:

mmm, I figured the problem, but don't know how to solve it.
my struct has a destructor which clears itself:

struct json_value
{
   ~this() { .ValueClear(&data); }
}

so how I can I put a struct in the heap? (not in the stack, as is 
the default..)

ed <ed ed.de> writes:

On Saturday, 23 April 2016 at 01:11:49 UTC, Ramon wrote:
 mmm, I figured the problem, but don't know how to solve it.
 my struct has a destructor which clears itself:

 struct json_value
 {
   ~this() { .ValueClear(&data); }
 }

 so how I can I put a struct in the heap? (not in the stack, as 
 is the default..)

new or make with arg or new or make then opAssign or this(this).

but have you tried

     __ghsared immutable json_value cbk = json_value(prms.argv[3]);

? without __gshared cbk might be on the TLS. (see with -vtls 
switch on DMD)

ag0aep6g <anonymous example.com> writes:

On 23.04.2016 03:11, Ramon wrote:
 mmm, I figured the problem, but don't know how to solve it.
 my struct has a destructor which clears itself:

 struct json_value
 {
    ~this() { .ValueClear(&data); }
 }

So the struct is destroyed at the end of DoDirSearch, despite there 
being a closure for it. Is the compiler doing the right thing here? 
Shouldn't the struct be considered alive until the closure gets garbage 
collected?

ag0aep6g <anonymous example.com> writes:

On 23.04.2016 07:35, ag0aep6g wrote:
 So the struct is destroyed at the end of DoDirSearch, despite there
 being a closure for it. Is the compiler doing the right thing here?
 Shouldn't the struct be considered alive until the closure gets garbage
 collected?

I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=15952