On Wednesday, 28 April 2021 at 22:05:31 UTC, sighoya wrote:
> Doesn't suffice ownership here? I mean you surely talk about owned manually allocated memory inside a class.

The compiler currently doesn't know about ownership, but you might have a non-owning pointer to a resource-manager-object that is guaranteed to outlive the program for instance.

> But why the need at all for a finalizer and instead allow non-empty destructors for gc allocated classes?
> Having both is confusing.

Because destructors should be reserved for deterministic destruction, where you can presume that there are no dangling pointers. You shouldn't be allowed to allocate such object on the GC-heap.

On the other hand, you should be allowed to subclass a GC-oriented finalizer based class and extend it with deterministic destruction.  I guess you could make the distinction some other way. The difference is that a finalizer is running on a partially destructed object, whereas a destructor is running on a valid object.

You don't need seperate functions at runtime, I guess, but the compiler has to know whether it is typechecking a finalizer or a destructor.

>> Or would it be better to simply forbid any cleanup in the GC? I kinda think so, but I also think many D users are used to letting the GC trigger cleanup on collection.
>>
>> What do you think?
>
> Probably not for gc managed resources, but what about making class members reference counted or owned instead.

That is the big question, is it really necessary to allow the GC to manage other resources than memory?

I guess you could do it also for file descriptors, with a precise collector. Then it would scan also file descriptors and release those that no longer are referenced. But that is kinda esoteric... :-)

> Owned resources should be deleted automatically when a class object is destructed and reference counted resources are deleted if refcount goes to zero, which may occurs after destruction but at least not before.

Yes, but this is tricky with a GC that isn't fully precise. The more objects that reference the ref-count the more likely you are to get a leak.

On Wednesday, 28 April 2021 at 21:36:54 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 April 2021 at 21:12:08 UTC, 12345swordy wrote:
>> How on earth are interfaces expensive?
>
> Look at the implementation?

That's an issue with the implementation not design.

-Alex

On Wednesday, 28 April 2021 at 23:24:38 UTC, 12345swordy wrote:
> On Wednesday, 28 April 2021 at 21:36:54 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 28 April 2021 at 21:12:08 UTC, 12345swordy wrote:
>>> How on earth are interfaces expensive?
>>
>> Look at the implementation?
>
> That's an issue with the implementation not design.
>
> -Alex

1. What's bad about the implementation (haven't looked)?
2. Can we fix it?

On Wednesday, 28 April 2021 at 17:05:55 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 28 April 2021 at 16:12:37 UTC, Kagamin wrote:
>> On Wednesday, 28 April 2021 at 10:04:20 UTC, Ola Fosheim Grøstad wrote:
>>> Anyway, if it isn't clear, the basic goal is to allow RC-based RAII and GC to coexist.
>>
>> You want synchronized RC?
>
> For shared, but not for nonshared?

GC is multithreaded, if RC is to be compatible, it should be multithreaded too, i.e. synchronized.

On Thursday, 29 April 2021 at 15:24:14 UTC, Kagamin wrote:
> GC is multithreaded, if RC is to be compatible, it should be multithreaded too, i.e. synchronized.

You cannot change anything that is traced during collection, so synchronizing won't help?

Another reason to move to per-task-GC, perhaps?

On Thursday, 29 April 2021 at 15:11:06 UTC, Imperatorn wrote:
> 1. What's bad about the implementation (haven't looked)?

From the ABI:

>An interface is a pointer to a pointer to a vtbl[]. The vtbl[0] entry is a pointer to the corresponding instance of the object.Interface class. The rest of the vtbl[1..$] entries are pointers to the virtual functions implemented by that interface, in the order that they were declared.


Imperatorn:
> 2. Can we fix it?

It could be made part of the vtable instead, but that requires more advanced linking.

It probably won't happen.

On Friday, 30 April 2021 at 10:44:07 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 29 April 2021 at 15:11:06 UTC, Imperatorn wrote:
>> 1. What's bad about the implementation (haven't looked)?
>
> From the ABI:
>
>>An interface is a pointer to a pointer to a vtbl[]. The vtbl[0] entry is a pointer to the corresponding instance of the object.Interface class. The rest of the vtbl[1..$] entries are pointers to the virtual functions implemented by that interface, in the order that they were declared.

The bad part is made more explicit here:

https://dlang.org/spec/abi.html#classes

As you can see, every object wastes 8 bytes per interface it supports. Ok if you only have 100 instances, not good if you have one million instances (would waste 8 megabytes per interface you support).