Array and variable handling / suggestion

[Shaggi]

1. Accessing temporary arrays

This could be a cool feature, and in many cases reduce code in larger expressions. Also, it will solve the problems explained later down. Example:

Func n()
	Local $Array[2] = [1,2]
	Return $Array
EndFunc

MsgBox(0,"",n()[1])

2. Ability to have 2 variables reference the same content.

This is already working through ByRef parameter passing, however when you return a referenced parameter it creates a copy. Example:

Global $Array[2] = ["foo","foo"]
$Array2 = n($Array)
$Array2[1] = "bar"
ConsoleWrite($Array[0] & @CRLF & $Array[1])

Func n(ByRef $Array)
	Return $Array
EndFunc

This is the same with normal variables.

3. Nested arrays / Arrays in arrays and linked lists

Since arrays can store other arrays, why cant you access them without getting bounds errors? This seems more like a faulty parsing case than a limitation within autoit:

#include <Array.au3>
Dim $a[2]
Dim $b[2]

$b[0]="foo"
$b[1]="foo"
$a[0] = "bar"
$a[1] = $b

_ArrayDisplay($a)
_ArrayDisplay($a[1])

ConsoleWrite($A[0])
ConsoleWrite($A[1][0]) ;Error

It seems that when arrays are assigned to elements of others, they are stored as temporary variables - maybe this is related to #1? If this could be fixed, it would allow many things - like a more structured design like linked lists or better ability to write something object oriented.
As it stands now, the only way to modify the contents of an nested array (without creating a copy of the index, modifying and assigning back) is through byref parameter functions, so you can access the element. Example:

#include <Array.au3>
Dim $a[2]
Dim $b[2]

$b[0]="foo"
$b[1]="foo"

$a[0] = "bar"
$a[1] = $b

_ArrayDisplay($a)
_ArrayDisplay($a[1])
Change($A[1])
_ArrayDisplay($a[1])

Func Change(Byref $A)
	$A[0] = "changed"
EndFunc

It is possible to do it this way, however when you have a nested array (c) inside a nested array (b) in a array (a), it's near impossible to change contents of c without creating a new array - because as #2 states, a ByRef parameter returned is a new copy. And since you can only access nested arrays through ByRef parameters, you actually have to create a recursive byref function, that "dereferences" the array each time. This is a costly process, and pretty stupid. Example:

Func _C_NestChangeVal(ByRef $Obj, $Val, $Ref1 = -1, $Ref2 = -1,$Ref3 = -1)
	Switch @NumParams
		Case 5
			_C_NestChangeVal($Obj[$Ref3],$Val,$Ref1,$Ref2)
		Case 4
			_C_NestChangeVal($Obj[$Ref2],$Val,$Ref1)
		Case 3
			$Obj[$Ref1] = $Val
	EndSwitch
EndFunc

I hope this will be implemented, and since (i think) AutoIt supports it all, it shouldn't be that hard to do.

[anonymous]

+1

...and literal arrays?
Local $a = ACreate()

Func ACreate()

Return ['1','2','3']

EndFunc

[trancexx]

Number 1 may seem like a good thing but really it should be this:

Func n($x)
	Local $Array[2] = [1,2]
	Return $Array[$x]
EndFunc

MsgBox(0,"",n(1))

Number 2 is not sensible request. If you want (and absolutely need) two variables referencing the same data then don't use array, use dllstruct type.

Number 3 is syntax mess considering current syntax rules for accessing arrays. Plus what's said already.

Anonymous's suggestion is bad from several aspects one of which is creating exception of rules.

Rejecting all.

[trancexx]

Small correction. Number one will be part of new beta.

[Shaggi]

Replying to trancexx:

Number 2 is not sensible request. If you want (and absolutely need) two variables referencing the same data then don't use array, use dllstruct type.

Number 3 is syntax mess considering current syntax rules for accessing arrays. Plus what's said already.

Anonymous's suggestion is bad from several aspects one of which is creating exception of rules.

Well i dont know, references are good for a lot of stuff imo. Looking at your old source it seems your variant supports references to others. As for three, it doesn't change the syntax in any way - only allows for direct access to these references or temporary variables, much like number 1?

Rejecting all.

:/

Small correction. Number one will be part of new beta.

good to hear you're looking at 1 though, looking forward to it.

[Valik]

References may be added someday but there are no plans to do so. If references are added it won't be tied to arrays, it will be a general mechanism that works with any variable.

As for accessing nested arrays... it wouldn't work how you think. I would love to add the syntax and indeed it's really no different than allowing StringSplit("a,b", ",")[1] which we now support. However, the key point in the StringSplit() example and in nested array access is that what you really access is a temporary object. Nested arrays would be read-only. Attempts to write to them would write to the temporary object which would be discarded at the end of the statement.

I know what you want to ask, can't you just make the temporary reflect back to the stored version when writing? Yes, in theory. However, that opens a can of worms because at first glance other more complex examples of using temporaries would also benefit from the temporary being reflected even though that behavior would be incorrect in those cases.

[Shaggi]

Replying to Valik:

References may be added someday but there are no plans to do so. If references are added it won't be tied to arrays, it will be a general mechanism that works with any variable.

Sounds good.

As for accessing nested arrays... it wouldn't work how you think. I would love to add the syntax and indeed it's really no different than allowing StringSplit("a,b", ",")[1] which we now support. However, the key point in the StringSplit() example and in nested array access is that what you really access is a temporary object. Nested arrays would be read-only. Attempts to write to them would write to the temporary object which would be discarded at the end of the statement.

I know what you want to ask, can't you just make the temporary reflect back to the stored version when writing? Yes, in theory. However, that opens a can of worms because at first glance other more complex examples of using temporaries would also benefit from the temporary being reflected even though that behavior would be incorrect in those cases.

Alright & thanks - I appreciate the thorough explanation :)