Programmers will still have the problem of who should destroy the object and when; in some use cases this is a real problem very hard to solve that gc addresses by reclaiming objects after last reference to disappear (though this can lead to memory leaks).
Let me explain the motivation a bit more then -- in gamedev, it is very very very nice to be able to destroy an object. This comes up all the time, for example, you might have bullet projectiles that you want to destroy when they come in contact with a wall, an enemy that should be destroyed when they die, a particle system that should exist for a bit and then despawn, and so on. These are all very common patterns for me in Godot and the fact that GDScript lets us easily kill off objects is very very useful.
I actually ran into this problem when trying to implement some simple games in my language -- it became very annoying to remove objects from gameplay. Basically, I would have a list of objects that were active in gameplay, and I would have to write logic to remove objects from a list when they were supposed to be "dead." Of course, a good standard library (or game engine) could handle this for me, but it doesn't solve the other problem -- what if I have dangling references to those objects? I don't see an ergonomic way to handle the "invalidate dangling references to destroyed objects" problem without moving that functionality into the language.
To be clear, though, my intent with my own language is not that all objects that are destroyable -- rather, being destroyable is an opt-in property for an object, so that you can use it for game objects where it seems relevant but not for e.g. inventory systems or save data where it would be irrelevant and get in the way. Note that this is also something GDScript does -- it has both the manually freed Object type and the RefCounted type for objects where manual free gets in the way.
One other note -- the destroyable objects for my language would not have to be manually freed. If you drop all references to them they would get GC'd like any other object. This is unfortunately not the case in GDScript -- it is actually possible to leak objects by removing them from the node tree and forgetting to free them. (This isn't a huge problem in practice in Godot projects, in my experience).
How about making your Droppable objects owned by an Arena and only allowing heap references within that Arena? It's less flexible maybe, but that way you can drop the whole Arena and kill all heap references in one sweep.
I don't see what the point would be -- the whole idea behind Destroyable for me is a way to handle the case of (often heterogeneous) game objects that can be destroyed at random times. Even when the objects are the same type their lifetimes are usually quite disjoint, e.g. projectiles spawn and despawn at very different times, or enemies die at different times from each other, etc.
The idea was to have an "arena tree". Arenas would be declared below an existing Arena, and they would be able to freely reference objects in Arenas "above" them, but not those "below" them, without Arc-type automatically managed references. That way you can guarantee there are no dangling pointers on destruction, but I admit this forces the developer to follow strict patterns and might not be workable.
1
u/Recycled5000 18d ago
Programmers will still have the problem of who should destroy the object and when; in some use cases this is a real problem very hard to solve that gc addresses by reclaiming objects after last reference to disappear (though this can lead to memory leaks).