On 5/19/15 4:16 PM, Namespace wrote:
> On Tuesday, 19 May 2015 at 20:02:07 UTC, rsw0x wrote:
>> "After dconf"
>> http://forum.dlang.org/thread/5554D763.1080308@dawg.eu#post-5554D763.1080308:40dawg.eu
>>
>
> I thought the new releases would come faster.

They should. This is an exception. Read the thread quoted above.

-Steve

On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
> On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous@anonymous.com> wrote:
>
>> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:
>>>
>>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>>> Is this also true for D?
>>>>
>>>> Yes. The GC considers all the unreferenced memory dead at the same time and may clean up the class and its members in any order.
>>>
>>> Ugh... I was really hoping D had something better up it's sleeve.
>>
>> It actually does, check out RefCounted!T and Unique!T in std.typecons. They're sort of limited right now but undergoing a major revamp in 2.068.
>
> Any idea what the plans are?. Does RefCounted become thread safe?
>
> Correct me if I'm wrong though, but even if RefCounted itself was thread-safe, RefCounted objects could still be placed in classes, at which point you might as well use a GC'ed class instead, because you'd be back to square-one with your destructor racing around on some random thread.
>

I don't understand what you're asking here. If you hold a RefCounted resource in a GC managed object, yes, it will be tied to the GC object's lifetime.

With your avoidance of the GC, I feel like you were lied to by a C++ programmer that reference counting is the way to do all memory management, when in reality reference counting is dog slow and destroys your cache locality(esp. without compiler support.) Reference counting is meant to be used where you need absolute control over a resource's lifetime(IMHO,) not as a general purpose memory management tool.

Bye.

On Tue, 19 May 2015 17:52:36 -0400, rsw0x <anonymous@anonymous.com> wrote:

> On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
>> Any idea what the plans are?. Does RefCounted become thread safe?
>>
>> Correct me if I'm wrong though, but even if RefCounted itself was thread-safe, RefCounted objects could still be placed in classes, at which point you might as well use a GC'ed class instead, because you'd be back to square-one with your destructor racing around on some random thread.
>>
>
> I don't understand what you're asking here. If you hold a RefCounted resource in a GC managed object, yes, it will be tied to the GC object's lifetime.
>
> With your avoidance of the GC, I feel like you were lied to by a C++ programmer that reference counting is the way to do all memory management, when in reality reference counting is dog slow and destroys your cache locality(esp. without compiler support.) Reference counting is meant to be used where you need absolute control over a resource's lifetime(IMHO,) not as a general purpose memory management tool.

Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking.

  Bit

On 5/19/15 5:07 PM, bitwise wrote:
> On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous@anonymous.com> wrote:
>
>> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
>>> <destructionator@gmail.com> wrote:
>>>
>>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>>> Is this also true for D?
>>>>
>>>> Yes. The GC considers all the unreferenced memory dead at the same
>>>> time and may clean up the class and its members in any order.
>>>
>>> Ugh... I was really hoping D had something better up it's sleeve.
>>
>> It actually does, check out RefCounted!T and Unique!T in std.typecons.
>> They're sort of limited right now but undergoing a major revamp in 2.068.
>
> Any idea what the plans are?. Does RefCounted become thread safe?
>
> Correct me if I'm wrong though, but even if RefCounted itself was
> thread-safe, RefCounted objects could still be placed in classes, at
> which point you might as well use a GC'ed class instead, because you'd
> be back to square-one with your destructor racing around on some random
> thread.

With the current GC, yes. RefCounted needs to be thread safe in order to use it. But if we change the GC, we could ensure destructors are only called in the thread they were created in (simply defer destructors until the next GC call in that thread).

> I'm finding it hard to be optimistic about the memory model of D.
>
> The idea of marking absolutely everything in your program with "@nogc"
> just to make it safe is ludicrous.

That makes no sense, the GC is not unsafe.

-Steve

On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On 5/19/15 5:07 PM, bitwise wrote:
>> On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous@anonymous.com> wrote:
>>
>>> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>>>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
>>>> <destructionator@gmail.com> wrote:
>>>>
>>>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>>>> Is this also true for D?
>>>>>
>>>>> Yes. The GC considers all the unreferenced memory dead at the same
>>>>> time and may clean up the class and its members in any order.
>>>>
>>>> Ugh... I was really hoping D had something better up it's sleeve.
>>>
>>> It actually does, check out RefCounted!T and Unique!T in std.typecons.
>>> They're sort of limited right now but undergoing a major revamp in 2.068.
>>
>> Any idea what the plans are?. Does RefCounted become thread safe?
>>
>> Correct me if I'm wrong though, but even if RefCounted itself was
>> thread-safe, RefCounted objects could still be placed in classes, at
>> which point you might as well use a GC'ed class instead, because you'd
>> be back to square-one with your destructor racing around on some random
>> thread.
>
> With the current GC, yes. RefCounted needs to be thread safe in order to use it. But if we change the GC, we could ensure destructors are only called in the thread they were created in (simply defer destructors until the next GC call in that thread).

This seems like it could result in some destructors being delayed indefinitely.

>> I'm finding it hard to be optimistic about the memory model of D.
>>
>> The idea of marking absolutely everything in your program with "@nogc"
>> just to make it safe is ludicrous.
>
> That makes no sense, the GC is not unsafe.
>
> -Steve

Maybe I worded that incorrectly, but my point is that when you're running with the GC disabled, you should only use methods marked with @nogc if you want to make sure your code doesn't leak right? that's a lot of attributes O_O

  Bit

On Tue, 19 May 2015 19:03:02 -0400, bitwise <bitwise.pvt@gmail.com> wrote:
> Maybe I worded that incorrectly, but my point is that when you're running with the GC disabled, you should only use methods marked with @nogc if you want to make sure your code doesn't leak right? that's a lot of attributes O_O
>
>    Bit

....which is why I am asking if there are any plans to implement something like @nogc for entire modules or classes.

  Bit

On Tuesday, 19 May 2015 at 23:10:21 UTC, bitwise wrote:
> ....which is why I am asking if there are any plans to implement something like @nogc for entire modules or classes.

At the top:

@nogc:
<stuff here>

Gotta do it inside the class too i think.

On Tue, 19 May 2015 19:16:14 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Tuesday, 19 May 2015 at 23:10:21 UTC, bitwise wrote:
>> ....which is why I am asking if there are any plans to implement something like @nogc for entire modules or classes.
>
> At the top:
>
> @nogc:
> <stuff here>
>
> Gotta do it inside the class too i think.


Thanks!

this seems to work too:

@nogc {
   <stuff>
}


I think this is still a problem though:

struct StackThing { ~this() { writeln("where am I?"); } }

class HeapThing{
    StackThing thing;
}

HeapThing thing = new HeapThing();

Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope.

I hope I'm wrong and DIP74 comes soon =/

  Bit

On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote:
> Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking.

And what you're asking. Just for the record: C++ memory management techniques are not designed to work in GC environment.

On Wednesday, 20 May 2015 at 03:44:58 UTC, bitwise wrote:
> Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope.

If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time.

On Wednesday, 20 May 2015 at 08:01:46 UTC, Kagamin wrote:
> On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote:
>> Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking.
>
> And what you're asking. Just for the record: C++ memory management techniques are not designed to work in GC environment.

Yes, but D claims to support manual memory management. It seems to get second class treatment though. I'm pretty sure I can PInvoke malloc in C# too ;)

> On Wednesday, 20 May 2015 at 03:44:58 UTC, bitwise wrote:
>> Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope.
>
> If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time.

 AFAIK D does not provide any built in functionality like Objective-C's 'runOnMainThread', which makes this a painful option.