Array declaration error (new behavior): Can not initialize a variable with itself

[jguinch]

Hello all.

Sometimes, i use this kind of array declaration :

Local $a = [1, $a[0] ]

This method of declaration worked before (I don't know which version, few monthes ago).

Is it a desired behavior, or a bug ?

[Melba23]

jguinch,

I am quite surprised that you say it used to work - I seem to remember this being discussed some time ago and the general consensus at the time was that such behaviour was not a good idea. So I would say: "feature", not "bug"

M23

[trancexx]

Of course it worked. The feature was controlled by Opt("MustDeclareVars").

This is script breaking change, which apparently isn't documented. If there was "general consensus" on this, then I question the ability of participants to make decisions like that.

[jguinch]

It worked next year : https://www.autoitscript.com/forum/topic/159554-paper-rock-scissors-challenge/?do=findComment&comment=1157805, https://www.autoitscript.com/forum/topic/160024-lottery-challenge/?do=findComment&comment=1162414

It doesn't matter, but I wanted to be sure it was a desired change, not a bug ...

 

[Melba23]

jguinch,

It seems my memory was not correct in this instance - sorry to have misled you.

M23

[jguinch]

no problem Melba

Now, I agree with trancexx : something should appear in the help file about this breaking change... Perhaps I should create a ticket in the bug tracker ?

[jguinch]

Ahh, note it is possible do use something like this to skip this restriction :

Local $a = [1, Execute("$a[0]") ]

 

[czardas]

Ahh, note it is possible do use something like this to skip this restriction :

Local $a = [1, Execute("$a[0]") ]

That isn't a viable solution because Execute() interprets the input as if it were a string - who knows what kind of data that will return.

I also have to agree with trancexx: it seems odd that this doesn't simply work out of the box. I am surprised that this (apparently logical) syntax no longer works.

Edited December 31, 2015 by czardas

[jguinch]

Yes czardas, I tought about that. I made some tests before my previous post and it seems to be not so bad : 

#include <Array.au3>

Local $b = [1, "a", ObjCreate("shell.application"), WinList(), True, Binary("0x00204060") , DllStructCreate("int;"), WinGetHandle("[ACTIVE]"), MsgBox, 3.14159, 50, _ 
            Execute("$b[0]"), Execute("$b[1]"), Execute("$b[2]"), Execute("$b[3]"), Execute("$b[4]"), Execute("$b[5]"), Execute("$b[6]"), Execute("$b[7]"), Execute("$b[8]"), Execute("$b[9]") ]


ConsoleWrite("$b[11] is an integer ? "  & IsInt($b[11]) & @CRLF)
ConsoleWrite("$b[12] is a string ? "    & IsString($b[12]) & @CRLF)
ConsoleWrite("$b[13] is an object ? "   & IsObj($b[13]) & @CRLF)
ConsoleWrite("$b[14] is an array ? "    & IsArray($b[14]) & @CRLF)
ConsoleWrite("$b[15] is boolean ? "     & IsBool($b[15]) & @CRLF)
ConsoleWrite("$b[16] is binary ? "      & IsBinary($b[16]) & @CRLF)
ConsoleWrite("$b[17] is a structure ? " & IsDllStruct($b[17]) & @CRLF)
ConsoleWrite("$b[18] is a handle ? "    & IsHWnd($b[18]) & @CRLF)
ConsoleWrite("$b[18] is pointer ? "     & IsPtr($b[18]) & @CRLF)
ConsoleWrite("$b[19] is function ? "    & IsFunc($b[19]) & @CRLF)
ConsoleWrite("$b[20] is float ? "       & IsFloat($b[20]) & @CRLF)
ConsoleWrite("$b[21] is number ? "      & IsNumber($b[21]) & @CRLF)

_ArrayDisplay($b)

 

[czardas]

Duh you are right, now I see my mistake. It's rather odd that the elements can't be referenced directly, yet they can still be accessed using Execute().

Edited December 31, 2015 by czardas

[czardas]

I'm surprised that this doesn't work:

Local $a[] = [0]
Local $a[] = [$a[0]]

... but then again, neither does this:

Local $a[] = [1]
Local $a[] = [Execute('$a[0]')]

 

Edited December 31, 2015 by czardas

[jguinch]

Logical, because you use Local to declare the variable, so it's like the first use...

This one works :

Local $a = [1]
Local $a[ $a[0] ] = [2]

 

Edited December 31, 2015 by jguinch

[czardas]

I wasn't aware of these restrictions on variable redeclaration. I thought the full expression was parsed evaluated before any impact on the original. That would seem consistent (syntax).

;Local $sStr = "string"
;Local $sStr = $sStr & $sStr ; error

$sStr = "string"
$sStr = $sStr & $sStr ; assignment works alright here

Edit: Perhaps it's just simpler for things to be the way they are.

Edited December 31, 2015 by czardas

[czardas]

I revise what I said in post #8. This is less intuitive than I at first thought: self-referencing (previous post) is not the same as back-referencing (first post). The syntax simply looked as though it ought to do something, although I haven't used it myself. I can see it being useful in both cases, but I don't know how other languages deal with this kind of thing.

[trancexx]

^^ For example, intuitive as you are, do you think C/C++ allows this:

char czardas[] = { 99, 122, 97, 114, 100, czardas[2], 115, 0 };

 

[czardas]

My intuition sometimes lets me down, but I like your example.

[Melba23]

Hi,

I have been racking my ageing brain trying to come up with a use case when such a "self-initialisation" functionality would be required - and signally failing to do so. The other thread participants appear to believe that the functionality should still exist, so could one of them please provide a sensible real-world example - rather than the "fun" scripts linked to in post #4 above.

M23

[czardas]

How about this - any use?

Local $aReplicate[] = [Random(0, 1, 1), ($aReplicate[0] ? True : False)]

 

[trancexx]

I would say that sensible real-world example would be any script that used to work and now it doesn't.

[guinness]

The code that was referenced earlier, my code, worked in v3.3.12.0 (just tested it a second a go). So seems to be a bug with the latest version.