Side Effects of Setting Handle.id Directly?

[zicklag]

If I understand correctly, because the id field of Handle<T> is public, if I set that field directly on a strong handle, it would fail to decrement the strong reference count for the previous handle ID, and then the asset previously referenced by the strong handle would never be dropped.

Am I understanding that correctly?

[mockersf]

I'm not sure on all the side effects that would have, but what you're describing seems correct 👍

The id field is public more for read access than write access... I guess a side effect of you opening that discussion will be a PR to make it private with an accessor 😄

[mockersf]

The "proper" way to go from a HandleId to a (strong) Handle<T> is through AssetServer::get_handle or Assets<T>::get_handle. Would those work for you?

I don't think there's a way currently to go from a HandleId to a weak Handle<T>, but I'm not sure that would be useful...

[zicklag]

I could use AssetServer::get_handle_untyped to get an UntypedHandle if UntypedHandle implemented Reflect. I don't know the type of the asset I'm loading when the script runs, so I can't use a typed handle in the script.

Then there is still the issue that I can't assign an untyped handle to a Handle<T> if that Handle<T> is currently in a &mut dyn Reflect.

Setting the ID worked because I can get the id field through the Reflect trait and then assign to it.

🤔

If we had reflect functions, like is being worked on here then we could expose a reflect function to create a strong handle from an untyped handle or a weak handle from a handle ID. That's probably the correct solution.

So maybe we do just make this private in Bevy and I'll just need to try and leverage reflect functions to do the conversion. Or I might just find another workaround for my use-case, 'cause I'm still working on fleshing it out.

[mockersf]

I hate what I'm going to write, but... making the field private doesn't stop you from changing it using reflection.

You'll just be committing two crimes instead of one 😄. And it would cleanup the public API

[zicklag]

LOL. I guess I might just be a criminal, then.

[mockersf]

#6176

[zicklag]

Looks like all of my concerns as far as scripting are covered by this PR: #5923! 🎉