This gives a compiler error: UFunctions cannot take a TObjectPtr as a parameter.
If I remove UFUNCTION(), it compiles fine.
I admit that I don’t understand when to use UFUNCTION and when not to… something about the reflection system… which as far as I can tell allows the function to be called/implemented in blueprints, and use in timers and delegates.
So why wouldn’t I want a function that takes a TObjectPtr as a parameter to be noticed by the reflection system? I’m probably missing something fundamental here, so I appreciate your patience.
Any tips on when and when not to use UFUNCTION or UPROPERTY are also welcome.
Will Epic ever implement this?
Currently this creates a bit sub-par experience for C++ heavy projects.
Ideally we would use TObjectPtr for all UObject based classes, but right now UFUNCTIONS require the use of normal pointers.
It is just a style issue but I think it would be worthwhile to implement this.
I just happened upon this as I saw in the migration guide for UE 5 that they encourage moving to use TObjectPtr, so I was making the changes and the same issue came up.
It’s weird, but it seems like internally they know this issue exists.
If it’s an issue at all that is.
Looking through some of their source code for the engine, places where changes have been made to use TObjectPtr are almost exclusively properties and as arguments in functions that don’t use the UFUNCTION macro.
It seems like a conscience decision in those places where it seems like this “issue” exists, to not have those functions marked with the UFUNCTION macro whether needed or not.
It’d be good to find out what is going on with this and how it’s intended to be used.