As a Roblox developer, it is currently too hard to …
Tell if an arbitrary instance is destroyed or not, simply listening to instance. Destroying is not enough. I do not want to have to cache the destroyed status of an arbitrary amount of objects, that defeats the purpose of destroying them.
If Roblox is able to address this issue, it would improve my development experience because …
it will be easier to migrate to the new destroy replication behavior, and I will not have to rewrite as much legacy code.
This works in every case I’ve found, except for when objects are intentionally parented to nil (almost never), or not fully initialized yet (damn you player.Character!).
Are there other cases where this property would make sense?
It’s exactly because a nil parent doesn’t imply destruction that it doesn’t “work”. It’s not a safe or accurate strategy of determining when an instance is destroyed especially in complex cases where you have a lot of instance management going on. Developers shouldn’t have to guess or use hacks to differentiate a nil-parented instance from a destroyed one be it for compatibility or a genuine use case that shows up.
This is the hackiest thing ever, but you can use this to determine if an instance is parent-locked, which is usual for destroyed instances.
local function IsDestroyed(Object: Instance): boolean
if Object.Parent == nil then
local Success, Error = pcall(function()
Object.Parent = UserSettings() :: any
end)
return Error ~= "Not allowed to add that under settings"
end
return false
end
The special thing about this is that trying to parent something to UserSettings() will always error, so you don’t have to worry about accidently changing the parent of a non-destroyed object. We just determine if the error was normal or not.