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

David Rönnqvist david.ronnqvist at gmail.com
Tue May 31 15:17:14 CDT 2016


> 31 maj 2016 kl. 21:37 skrev Chris Lattner <clattner at apple.com>:
> 
>> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution <swift-evolution at swift.org> wrote:
>> Lazy evaluation when assigning static variables
>> 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
> 

Did I understand it correctly that, under such a proposal, there would be no compiler magic for global properties and instead both global, type, and instance properties would be controlled by property behaviors (or lazy/atomiclazy until they are replaced by property behaviors)?

`lazy` having he current a behavior of lazy properties (no threading guarantees, not evaluating on assignment),
`atomiclazy` having the current behavior of static properties (guaranteed to only evaluate once when accessed from multiple threads, evaluating even on assignment)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/983f0310/attachment.html>


More information about the swift-evolution mailing list