[swift-evolution] SE-0030 Property Behaviors

Joe Groff jgroff at apple.com
Fri Feb 12 15:59:47 CST 2016


> On Feb 12, 2016, at 1:45 PM, Taras Zakharko <taras.zakharko at uzh.ch> wrote:
> 
> I like Anton’s proposal much better! Clean, obvious and down to the point. 
> 
>> On 12 Feb 2016, at 21:44, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> IMO it's unacceptable to have to store a closure for every individual lazy property. That significantly increases the storage cost of the abstraction.
>> 
>> -Joe
> 
> Maybe I am missing something obvious here but what would be a practical example of a lazy variable that does not rely on a closure to provide the initial value? Besides, storing an additional pointer per property is what, 8 bytes overhead? Barely worth mentioning. And of course, if you want to be very efficient about it you can always use a global hash map to store the closures. 

A Swift closure is two pointers wide—a function pointer, and a context pointer. The per-instance overhead for Optional<T> will already cost a word for many types without an extra bit or representation for 'None'.

> BTW, the lazy implementation you propose also has additional overhead, but its hidden (initialValue needs to be stored somewhere before the first call to get). In fact, your solution might be even worse in terms of storage overhead, because it implies that individual closure with unique environment needs to be created for getters of every instance of the property with different initialiser. 

As currently implemented, 'lazy' inlines the initializer expression into the property's getter implementation, so the only overhead is some code size in the getter function. A behavior implementation of [lazy] needs to afford the same opportunity to the optimizer. One way we could model this is as 'static' members in the behavior, perhaps.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160212/27f5ddc7/attachment.html>


More information about the swift-evolution mailing list