It looks like we have a situation where default initialization doesn't work in the loop because local variables need to be "hoisted" to function scope. In Flash, the variable would have been initialized before the loop started, and js-default-initializers will need to implement that behavior. I will work on that.
Unfortunately, this issue will affect any type of variable, and not just the ones that default to null. Boolean, Number, and int/uint will be affected too. So, it's a bug in how js-default-initializers is implemented, and not specifically related to variables that are initialized to null. Just like false for Boolean, NaN for Number, and 0 for int and uint, defaulting to null instead of undefined for String, Object, and everything else preserves the behavior that developers are used to. Technically, only the * type is supposed to be able to hold the undefined value. We could make the exact types that are initialized configurable, I suppose. Maybe like this: //everything -js-default-initializers=true //only some specific types -js-default-initializers=Boolean,Number - Josh On 2019/03/19 10:34:05, Harbs <[email protected]> wrote: > The latest compiler changes exposed a problem: > > for(var i:int=0;i<len;i++){ > var foo:Object; > if(someCondition(thingy[i]){ > foo = calculateFoo(thingy[i]); > } > doSomethingWithFoo(foo); > } > > Compiles to: > for(var i=0;i<len;i++){ > var foo = null; > if(someCondition(thingy[i]){ > foo = calculateFoo(thingy[i]); > } > doSomethingWithFoo(foo); > } > > This is a change from the intended behavior and foo is nullified in each step > of the loop. This can cause doSomethingWithFoo(null) even when foo was a > valid value in a previous iteration. > > I’d suggest two things: > > 1. I don’t see the value of initializing Objects to null at all. I’m not sure > why that became the default. I’d vote for not defaulting to initializing > Objects (just other types). > 2. Local values of any type should not be initialized in a loop. > > Harbs
