This feels like a Lucee compatibility bug to me: https://www.trycf.com/gist/f40c924b1651fd4ecb22d8837e48c568/acf2016?theme=monokai

<cfscript>
function test(){
    var local = {modified=""};
    
    return local.modified;
}

writeDump(test());
</cfscript>

When you run the above in any version of ACF, the

test()

function returns an empty string. However, in Lucee it throws a

key [MODIFIED] doesn't exist on line 3

exception. Should I file a bug for this?

not sure what you're trying to demonstrate, but

var local

is already problematic. if you return just local rather than local.modified, you get expected results. you're overwriting local with the code above and not sure what you think should be happening?

This is some legacy code I ran into. It used to be very common developer practice to use the variable

local

as when CFML did not have a proper

local

scope. Sometimes people did this so they didn't have to

var

declare every variable and could just create variables as needed. So it wasn't uncommon to see code like in the above example. I just happened to be working on migrating some older code that was using that syntax. It still works in ACF, which is why it was not noticed.

i recall that and see plenty of legacy code myself using the technique, but it became unnecessary in cf9 or 10 and i seem to recall it being really bad in railo/lucee v4.x as it obliterated the local scope when you did it

Yeah, Lucee basically ignores any declaration of

var local =

regardless of what's on the right hand side

yep, you can write it, but lucee will always bypass it and return the local scope

But Lucee doesn't allow you to create a variable named after a scope

Lucee doesn't seem to mind if I change

local

to

session

in that example...?

runtime variable name checking overhead for all CF scopes names? bit of a performance overhead for a rare edge case