[swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[Joe Groff]

> On May 31, 2016, at 5:54 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> On May 31, 2016, at 6:20 PM, Joe Groff <jgroff at apple.com> wrote:
>>> If the goal was to remove magic from the compiler, then a possible direction would be to do something like:
>>> 
>>> 1) Introduce a new declmodifier named something like “atomiclazy”.
>>> 2) Disallow global and static variables, unless they are explicitly marked atomiclazy (compiler would provide a fixit hint to suggest this).
>>> 3) Replace the atomiclazy magic with a property behavior when they exist.
>> 
>> This doesn't make sense. This "magic" is the only sensible way to initialize a global that requires dynamic initialization. Even with property behaviors, we would need to lazily apply the behavior's initialization logic to get the property into its initial state. Nonatomic lazy would be a misoptimization—it's hard to beat dispatch_once at its own game.
> 
> Why couldn’t a "sufficiently advanced" property behavior provide the same static initialization guarantees (e.g. its initialization is statically known) for its stored property, and then use dispatch_once as its implementation?  The compiler doesn’t know anything magic here.

There's quite a bit of magic about global initialization—it knows it can hoist and fold initialization checks, and how to turn effectively constant initializations into static initializations and avoid the laziness altogether. dispatch_once furthermore only works for global initializations, since its token is magic and must be statically initialized to zero at process start. Since our existing global initialization implementation only works for globals, and does the right thing for 99% of globals, this seems like foolish generalization to me, punishing the common case and opening opportunity for user mistakes for no gain.

-Joe