RefInOut (please follow your own Standards in naming your macros…)
current behavior
// to have a argument passed-by-reference and then returned
UFUNCTION(BlueprintCallable)
MyObjectType SetReturnValue( UPARAM(ref) MyObjectType& inMyObjectType)
{
//do work on inMyObjectType
//do work on or assign to internals
return inMyObjectType;
}
// to have multiple arguments passed-by-reference and returned
UFUNTION(BlueprintCallable)
void MultiPassInReturn( UPARAM(ref) MyObjectTypeA& inMyObjectTypeA, UPARAM(ref) MyObjectTypeB& inMyObjectTypeB, MyObjectTypeA& outMyObjectTypeA, MyObjectTypeB& outMyObjectTypeB)
{
//do work on inMyObjectTypeA and inMyObjectTypeB
outMyObjectTypeA = inMyObjectTypeA;
outMyObjectTypeB = inMyObjectTypeB;
}
desired behavior
//to have a argument passed-by-reference and then returned
UFUNCTION(BlueprintCallable)
void SetReturnValue( UPARAM(RefInOut) MyObjectType& inMyObjectType)
{
//do work on inMyObjectType
//do work on or assign to internals
}
//to have multiple arguments passed-by-reference and returned
UFUNTION(BlueprintCallable)
void MultiPassInReturn( UPARAM(RefInOUt) MyObjectTypeA& inMyObjectTypeA, UPARAM(RefInOut) MyObjectTypeB& inMyObjectTypeB)
{
// do work on inMyObjectTypeA and inMyObjectTypeB
// do work on Interals based on inMyObjectTypeA and inMyObjectTypeB
}
As of current on the blueprint side the default behavior of a UFUNCTION(BlueprintCallable) defines a pass-by-reference as an output pin, and then a given argument can be marked-up with UPARAM(ref) to make it an input pin, but to have it be both an input and an output in blueprints:
-for a single return of the function can be defined and then specifically returned through the functions return value similar to an operator+=(RHS) but a possible use case is to expect the argument to be chanced; as if it is (non-const)-passed-by-reference the receiving function has the right to modify it. on the blueprints side that is not what is reflected.
-for multiple variables it is reasonable to have multiple arguments passed-by-reference with either the expectation or understanding that they may be modified, and for some situations that is the intention, and we can semi-reasonably return Value for 1 thing, but any more and we need to create a separate argument with the intention of them being empty. on the C++ side the argument should be filled and passed in (maybe on a rare situation pass the same variable twice which just doesn’t feel right), but on the blueprint side it is just an output pin handled by the script-VM that just so happens to call down to C++
(DefaultValue)
current behavior
UFUNCTION(BlueprintCallable)
void SetValue(const int& inValue = 50){/*sets the value*/}
desired behavior
UFUNCTION(BlueprintCallable)
void SetValue(UPARAM(DefaultValue) const int& inValue = 50){/*sets the value*/} // would mostly be usable if the macro is a flag to look ahead and allow for no assignment
// or
void SetValue(UPARAM(DefaultValue=50) const int& inValue = 50){/*sets the value*/} // would mostly be usable if the value is simply expressed and for things that would call a trivial constructor
if the user calls the (current behavior) function in blueprints the blueprint will not compile if the pin for inValue is not set because it is const int& where in C++ it is completely valid for the argument to be left blank because it has a default value. I know the UBT and UHT don’t read the exact signature as written, and there could be edge cases where the function has 4 arguments each with default values each of the same Type, but in blueprints the user only attaches to pins 1, 2, & 4 (the blueprint user recognizing that there is a default value, and accepting that value) where either the script-VM would take the default value defined in the header and just plug it into the call to the C++ function as though all the arguments were entered.
*ADD Documentation for UPARAM similar to that of UFUNCTION(), UPROPERTY(), and UCLASS()
as of current the only official documentation for UPARAM is almost a side note in docs (exposing Gameplay to Blueprints) that isn’t easily findable (the 3rd link on a search for “unreal engine UPARAM” (you almost need to know it is there), so unless the programmer knows of its existence, has exhaustively read this specific docs page that mentions it, or searches for something like “Unreal Engine pass by reference is output” to then be told of UPARAM(ref) existing which still does not address the valid use-case of a reference argument being both input and modified output.
As far as I know there are 3 UPARAM() macros which only 2 of which are mentioned very briefly as a side note in 1 docs page, and doing a GOTO definition for UPARAM(ref) in Visual Studio returns 2 locations in type_traits (the internal Visual Studio file) and there is nothing listed for them in ObjectMacros.h (which is almost directly copy-pasted to make the docs pages for UCLASS, UPROPERTY, and UFUNCTION anyways)