On 2014-04-30 21:51:18 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> I'm thinking e.g. non-interlocked refcounts go like 1, 3, 5, ... and interlocked refcounts go like 2, 4, 6, ...
> 
> Then you do an unprotected read of the refcount. If it's odd, then it's impossible to having originated as an interlocked one. So proceed with simple increment. If it's even, do an interlocked increment.

Nice idea, although I'd add a twist to support polymorphism in class hierarchies: add a magic value (say zero) to mean "not reference-counted". When you instantiate an object that has a destructor, the reference counter is set to 1 or 2 depending on whether it's shared or not. If however the object has no destructor and is not reference counted, set the counter to the magic value.

Then have the compiler assume all objects are reference counted. At runtime only those objects with a non-magic value as the reference count will actually increment/decrement the counter.

Finally, let the the compiler understand some situations where objects are guarantied to have no destructors a destructor so it can omit automatic reference counting code in those cases. One such situation is when you have a reference to a final class with no destructor. We could also add a @nodestructor attribute to forbid a class and all its descendants from having destructors.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 4/30/2014 1:57 PM, deadalnix wrote:
> I already commented on past similar proposal. These are piling up more and more
> hacks to achieve roughly the same thing, badly. This makes it impossible to
> provide a 3rd party implementation that is compliant, is guaranteed to ends up
> in a nightmarish explosion of special cases, or to be vastly underpowered.

Actually, I think inference of the ability to implicitly and safely convert from mutable to immutable or shared to be very powerful. I also think it is superior than requiring the user to add ever more annotations, which some research (and my experience) shows that users are reluctant to do.

I don't buy that it is hackish, etc., especially without more of a rationale as to why.

A link to your previous comment would be useful.

On 4/30/2014 4:17 PM, H. S. Teoh via Digitalmars-d wrote:
> If we're going
> to have dtors at all, let's do it *right*. Guarantee they always work,
> and reject all usages that break this guarantee (like putting a struct
> with dtor inside a class,

Seems to work when I try it:

bar.d:
-------------------------
  import core.stdc.stdio;

  struct S { ~this() { printf("S.~this()\n"); } }

  class C { S s; }

  void main()
  {
    C c = new C();
    c = null;
  }
-------------------------
C:\cbx\mars>bar
S.~this()

On Thursday, 1 May 2014 at 01:20:37 UTC, Walter Bright wrote:
> On 4/30/2014 1:57 PM, deadalnix wrote:
>> I already commented on past similar proposal. These are piling up more and more
>> hacks to achieve roughly the same thing, badly. This makes it impossible to
>> provide a 3rd party implementation that is compliant, is guaranteed to ends up
>> in a nightmarish explosion of special cases, or to be vastly underpowered.
>
> Actually, I think inference of the ability to implicitly and safely convert from mutable to immutable or shared to be very powerful. I also think it is superior than requiring the user to add ever more annotations, which some research (and my experience) shows that users are reluctant to do.
>
> I don't buy that it is hackish, etc., especially without more of a rationale as to why.
>
> A link to your previous comment would be useful.

I've written several proposal regarding this. Please at least read them as what you just wrote only proves you are not well informed.

Notably, the proposal do not require annotations from the users to do the kind of things are are currently being special cased.

On 4/30/14, 6:04 PM, Steven Schveighoffer wrote:
> destructors are for cleaning up non-GC resources. File handles, malloc'd
> memory, etc. I don't see why these need to be eliminated.

Virtually all GCs are known to be horrible at managing scarce resources (including memory itself). Giving the task of managing such to the GC is like making the cross-eyed guy be the shooter in https://www.youtube.com/watch?v=sen8Tn8CBA4.

Andrei

On 4/30/14, 6:51 PM, Andrei Alexandrescu wrote:
> On 4/30/14, 6:04 PM, Steven Schveighoffer wrote:
>> destructors are for cleaning up non-GC resources. File handles, malloc'd
>> memory, etc. I don't see why these need to be eliminated.
>
> Virtually all GCs are known to be horrible at managing scarce resources
> (including memory itself).

Here the paren means "... when memory is scarce". GCs work well only in 3x+ the memory needed. -- Andrei

On Wed, 30 Apr 2014 21:51:38 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/30/14, 6:04 PM, Steven Schveighoffer wrote:
>> destructors are for cleaning up non-GC resources. File handles, malloc'd
>> memory, etc. I don't see why these need to be eliminated.
>
> Virtually all GCs are known to be horrible at managing scarce resources (including memory itself).

The destructor can be a crutch, but it's not good to leave open resources when the user of your code has not cleaned them up manually.

I can see no reason to disallow destruction from cleaning up resources that nobody else has managed to clean up.

The largest problem with D destructors comes from trying to clean up D objects in destructors of structs, that you never expected to be done via the GC.

Cleaning up files and malloc'd memory is not an issue.

-Steve

On 4/30/2014 6:50 PM, deadalnix wrote:
> On Thursday, 1 May 2014 at 01:20:37 UTC, Walter Bright wrote:
>> A link to your previous comment would be useful.
>
> I've written several proposal regarding this. Please at least read them as what
> you just wrote only proves you are not well informed.
>
> Notably, the proposal do not require annotations from the users to do the kind
> of things are are currently being special cased.

A link would be nice.

On 4/30/14, 7:20 PM, Steven Schveighoffer wrote:
> On Wed, 30 Apr 2014 21:51:38 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 4/30/14, 6:04 PM, Steven Schveighoffer wrote:
>>> destructors are for cleaning up non-GC resources. File handles, malloc'd
>>> memory, etc. I don't see why these need to be eliminated.
>>
>> Virtually all GCs are known to be horrible at managing scarce
>> resources (including memory itself).
>
> The destructor can be a crutch, but it's not good to leave open
> resources when the user of your code has not cleaned them up manually.

Sounds like defensive programming to me.

> I can see no reason to disallow destruction from cleaning up resources
> that nobody else has managed to clean up.

Make memory management faster and better for everyone. I'm not saying it's reason enough, but it's a reason.

> The largest problem with D destructors comes from trying to clean up D
> objects in destructors of structs, that you never expected to be done
> via the GC.
>
> Cleaning up files and malloc'd memory is not an issue.

Not getting this...


Andrei

On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
> That means classes that need cleanup (either directly or by having fields that are structs with destructors) would need to garner that by other means, such as reference counting or manual. We're considering deprecating ~this() for classes in the future.

I can't claim it should be done, but any time I've thought something should go in the destructor I was wrong and would end up with a close() or similar function.