Multiple Reference Variables returned (byref) in Functions and Subroutines

[Corso-1]

Hi, total Newbie for GDScript, strong VB6 coder.
In VB we have variables passed by reference to functions and subs as the default.
I'm requesting a discussion or implementation of a commonly available operation like VB6 has in regards to handling multiple referenced variables in Subs and Functions.

VB6 Example: Printing x,y,z after updating them via a function (passed by reference)

Sub Start_Program
Dim x=1 as integer: Dim b="My String" as string: Dim c =2.4 as single {Declare variables}
call do_something( x, y, z) {Call the function}
print(x,y,z) {Print the returned result}
end {End program}
Sub _do_something( byref A as integer, byref B as string, byref C as single )
A = A + 1
B = B & " added to string"
C = C + 5.6 {Adjust all given entries}
Exit Function

Result from printing x,y,z:
2, My String added to string, 8.0

The alternative way to do this in VB is: (as byref is the default) 'By reference' {ie: no need to declare}
_do_something( A as integer, B as string, C as single )

To send a copy of the values without returning them in VB is via this: (byval) 'By value'
_do_something( byval A as integer, byval B as string, byval C as single )

When you have 'several layers deep' function calls, sending byref variables is absolutley necessary, for example
Manipulating piercing damage to hand armour, body armour, arm armour all at once, but then pushing those variables further down into other functions because you need to add ice damage, then blunt damage, then acid damage. Or some other deeper layer and pertinent calculation (inside the Piercing Damage function). Eventually you recieve all armour sections updated without having to go through convoluted staging.

Ie:
call _add_piece_damage(MyArmour(a),MyArmour(b),MyArmour(c))
call _add_ice_damage(MyArmour(a),MyArmour(b),MyArmour(c))

The reciever sub or function looks like this:
Sub _add_piece_damage( byref ArmourPart1 as int, byref ArmourPart2 as int, byref ArmourPart3 as int)
Likewise the same style for others
Sub _add_ice_damage( byref ArmourPart1 as int, byref ArmourPart2 as int, byref ArmourPart3) {Note ArmourPart3 is a 'variant' here}

Functions and Subs behave in exaclty the same manner, but the Function usually returns a set 'thing' as well.
Ie: x = _call_my_function(a,b,c) {a,b,c defined earlier}

Function _call_my_function(g,h,i) as single {will return a single type value, in VB, all of these variables are byref(!)}
_call_my_function = g + h + i + 10.5
exit Function

With Godot sending value only variables, I've found this irregular and limiting.
For example, below is a Function that returns a colour pixel value, AND, updates any coordinate system given to Map_X & Map_Y which are Absolute Coordinates. (Those coordinates are then used in further functions. The function accepts ANY coordinate system initially too, Print_X & Y are mouse click locations, Tile_Number is an isometric tile on the map)

Public Function Return_Pixel_Colour_From_Layer_From_Any_Coord_Type(ByVal My_Map_Layer As String, Optional ByVal Print_X As Single = 0, Optional ByVal Print_Y As Single = 0, Optional ByRef Map_X As Integer = 0, Optional ByRef Map_Y As Integer = 0, Optional ByVal Tile_Number As Integer = 0) As Long

I don't know if Godot uses 'Optional' yet, but it is super handy in VB.

Having and parsing Byref variables into functions and subs is common, I'm just not certain as to why Godot doesn't have this straight up?

[theraot]

The influences of GDScript are mainly Python and Lua which do not have this feature.

Furthermore, from what I've heard this might not be straightforward to add to GDScript. On the flip side having to maintain references to caller local variables would have made yield/await more complex. Right now the code can resume the execution from the middle of a function without having to reconstruct a stack with references (and without a compiler heavily rewriting the code into continuations, which is the case of await in C# and VB.NET).

In fact, in GDScript captures are not treated as the same variable:

var x:String = "X"
    var f := func() -> void:
    x = "Y"
    prints("Inside:", x)

f.call()
prints("Outside:", x)

Outputs:

Inside: Y
Outside: X

See: #8558

---

Our workaround is to pass an Array:

var x:Array[String] = ["X"]
var f := func() -> void:
    x[0] = "Y"
    prints("Inside:", x[0])

f.call()
prints("Outside:", x[0])

Or:

func _ready() -> void:
    var x:Array[String] = ["X"]
    my_func(x)
    prints("Outside:", x[0])

func my_func(x:Array[String]) -> void:
    x[0] = "Y"
    prints("Inside:", x[0])

Outputs:

Inside: Y
Outside: Y

This is similar to the workaround of passing a list in Python.

---

Let us say we want to make byref and byval as Syntactic sugar for the above workaround...

Syntactic sugar for the parameter declaration is easy: byref x:String could be translated to x:Array[String].

But on the caller side it is not so much because they mean to use a different transformation depending on the parameter of what is being called, and that might not be known.

Furthermore, if I want to pass byref something that isn't it would mean a more complex transformation that just changes the line being executed (it means changing the type of the variable and everywhere it is being used).

---

Right now, I believe the path for GDScript would be along the lines of returning tuples (#2944) or shaped arrays/dictionaries (what reduz is calling "structs'' #7329). The syntactic sugar for that would be much easier to add to GDScript, but it is not here yet.

And yes, you can return an Array or Dictionary with multiple values today.

Anyway, I gave you a workaround, hopefully that is good enough for you.

---

On the flip side, yes GDScript has optional parameters by specifying the default value (there is no concept of missing) but unlike other languages the default value does not have to be a constant, it can be an expression evaluated on runtime!

[Corso-1]

Thank you Theraot for writing that. It makes me feel like my arms are chopped off without instant variable byref's. The top mini code above is a bit over my head so I'll look more into it. I get the last one though.

I was using something along the lines of (all pseudo code below)
_some_start_function():
var G = 1.0 {New variables}
var H = 2.5
var My_Array = [G,H] {New array}
_update_variables(My_Array ) {do a function on them}
G = My_Array[0] {update the original variables}
H = My_Array[1]

_update_variables(A):{Function that receives an array}
A[0] = 1.1{do the thing}
A[1] = 2.6
return[A]{return the data}

Same as above, VB scenario
Sub _update_variables(X,Y)
X=1.1
Y=2.6
exit sub

So, is that what I need to do from now on? Stage all data into an array then unpack it later, just to get byref functionality?
I've so much byref code to convert that it's making me want to cry ... :(

[theraot]

It is likely that there is a better alternative if we have a more holistic view.

Consider for example the following: In VB6 you had modules and class modules, but in GDScript every Script is a class. Not only that, but you can have nested classes.

So you might be able to create a class for the intended use of classes: encapsulate data alongside the operations you want do on that data, and then pass the object, and that will be a reference because objects are a reference type.

Also GDScript (as shown in my example) has anonymous methods that you can set to variables. The type is Callable, and you can either create them from an anonymous method, or from a regular one. And since they are a value, you can pass them as parameters too. So perhaps a design where you pass continuations is viable (i.e instead of getting the data back, you pass a method to be called with the data).

Futhermore, you have signals (which are similar to VB6 events), except connection is not declarative (you get connect and diconnect methods).

---

So this is my suggestion to port to GDScript: figure out what is the path of your data. It should be some graph of steps from input to output (and perhaps storage is involved), then you can figure out an appropiate way to implement that path in GDScript.

---

But what if you don't have to port to GDScript?

It should be possible to convert the C# project that the .NET version of Godot generates to VB.NET. I know that it is easier with Godot 4 than Godot 3 because Godot 4 it is using SDK format for project files, and that VB.NET can make a CLSCompliant assembly and can consume assemblies made for C#. And, of course VB.NET can use byval and byref.

[Corso-1]

Thanks again Theraot. I'm very familiar with VB6 classes, so I'll try to figure out what GDScript classes are and how they are different. One person was already saying that might be the best workaround solution in this case. I mostly used classes for interface components though.

I'll have to wrap my head around 'callable' things, though, I can't percieve how in my case variables as functions would work. Per, say a monster attack, A crap tonne of info is transported down, Character1 & Character2's entire SQL instances, then clothing/limb and physical/limb data and so on, and so on. All of that gets managed in modules-subs-functions depending on the attack etc. And all those functions call up other subs to work out data/situations on the fly (unrelated to Characters, ie: weapons, armour data etc).

Anyhow, you've given me some things to dig around with, many thanks!

Ah, I know nothing of VB.Net, other than it's poison. petwooehy.

Cheers