> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution > <[email protected]> wrote: > Lazy evaluation when assigning static variables > > <https://github.com/d-ronnqvist/swift-evolution#introduction>Introduction > > Both stored type properties (static) and lazy stored properties (lazy var) > are lazily initialized. However, they have different initialization behavior > in that stored type properties evaluate even when assigning them a new value. > > The following code will print "static", but not "lazy": > > class Foo { > static var bar: String = { > print("static") > return "Default" > }() > > lazy var baz: String = { > print("lazy") > return "Lazy" > }() > } > > Foo.bar = "Set" // this evaluates the initial value of `bar` before setting a > new value > > let foo = Foo() > foo.baz = "Set" // this doesn't evaluate `baz` before setting a new value This seems like a step in the right direction, but may not big a step far enough. Keep in mind that “static” and global variables are quite different than lazy variables, both in terms of implementation and behavior but also in terms of planned future direction.
“lazy” is almost certainly to be replaced by property behaviors in the future, making them a library defined feature whose behavior can be changed arbitrarily, and can hopefully have useful additional functionality like a “reset()” method added to them. Global variables are currently not like that: their behavior is defined by compiler magic instead of by property semantics. 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. In this model, you’d presumably have the choice about atomiclazy or lazy when setting up either a static or a local property. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
