bit of an odd question: Used to do lots of

blah = structNew()
blah.a = 1
blah.b = 2

years ago. Now using more like

blah = { a = 1, b = 2}

. My question is which of these two this (newer way using inline struct literal) would translate to under the hood:

// Door No. 1
blah = structNew()
blah.a = 1
blah.b = 2

// Door No. 2
_someSHAhashTemp = structNew() // just guessing here; the actual implementation isn't important, just the order of operations
_someSHAhashTemp.a = 1
_someSHAhashTemp.b = 2
blah = _someSHAhashTemp

That is, when the actual assignment operator is handled to set

blah

, is it given the fully-baked struct that already has keys

a

and

b

, or is it pointed at a new empty struct which is then populated?

Prolly depends on the engine

I guess more asking if (in, say ACF) if struct literals are first class or if they're syntactic sugar over a Door No. 1, which would mean

blah

points, for a very brief time, to an empty struct.

I don't see how it matters

which shouldn't matter... unless you open pandora's box of shared mutable state bwahahaha

So no code could use the struct prior to its population

like the session scope

The struct literal declaration is an atomic operation so far as your code is concerned

ah, ok. my example was boiled down a bit too far. I'm looking at a case where it's actually more like

blah = {c: 3, d: 4}
blah = {a: 1, b: 2}

Well, I can't prove that with ACF. We could dig through Lucee's source to find out

it would be difficult to demonstrate, for sure. I'm trying to rule out a race condition where a struct that shouldn't be empty is ending up that way.

I know for certain Boxlang doesn't assign the struct into the scope until its creation is complete. I would be very surprised to learn Adobe or Lucee did anything different

it would seem like a problematic design decision if they went that way, for sure

@mithlond Here is a quick test that declares a struct literal with 5000 keys https://trycf.com/gist/acd9d8f3a516beb740daf5970ccfd7eb/acf2023?theme=monokai