Andy found a bug where param defaults were not being correctly generated in this case:
static Void foo(Int a := 9, Int b := a)
The problem is that b defaults to use a, but a is itself a default. When you go to generate the no argument version of foo() it resulted in a verification error because b was attempting to access a even though a was never set explicitly.
I decided to handle this in the compiler versus the runtime since it would be a performance issue to do an extra store for every default parameter. Now the compiler scans for this case, and inserts the store instruction:
brian Wed 21 Jun 2006
Andy found a bug where param defaults were not being correctly generated in this case:
The problem is that b defaults to use a, but a is itself a default. When you go to generate the no argument version of foo() it resulted in a verification error because b was attempting to access a even though a was never set explicitly.
I decided to handle this in the compiler versus the runtime since it would be a performance issue to do an extra store for every default parameter. Now the compiler scans for this case, and inserts the store instruction:
sys::Void bar(sys::Int a, sys::Int b) [public static] [Param 0] a: sys::Int 0: LoadInt 9 3: Dup 4: StoreVar 0 [Param 1] b: sys::Int 0: LoadVar 0 [Code] 0: ReturnVoid