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

[Chris Lattner]

> 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.

-Chris