[swift-evolution] SE-0030 Property Behaviors

Taras Zakharko taras.zakharko at uzh.ch
Fri Feb 12 15:45:58 CST 2016


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

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. 

— Taras

> On 12 Feb 2016, at 21:44, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 12, 2016, at 12:08 PM, Антон Жилин <antonyzhilin at gmail.com <mailto:antonyzhilin at gmail.com>> wrote:
>> 
>> First of all, I insist that a deadline of less than 1 week is extremely tough for this specific proposal. There are just too many details that we need to work out, too many approaches to the problem that we want to consider. As many people as possible should be able to express ideas on this. A special request to core team is to extend the review to 2 week at least, or even more if it will be needed.
> 
> I'm inclined to agree. I'd be happy to extend the review period.
> 
>> 
>> I dislike the proposal as it is, especially the syntax. I think that rolling out a language feature and "bikeshedding" it is only right if we are ready to settle with most (although not all) of it. It's not the state of things currently.
>> 
>> I have prepaired a draft (not real proposal) of my vision on the problem. I tried to look at it from the other side, using existing Swift terms where possible. Some wording or details might be off. Link to the gist:
>> 
>> https://gist.github.com/Anton3/f71a3e2ee29dffe1b9b2 <https://gist.github.com/Anton3/f71a3e2ee29dffe1b9b2>
> public behaviour lazy<ValueType> {
>     private var storage: ValueType? = nil
>     private var closure: (() -> ValueType)?
> 
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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


More information about the swift-evolution mailing list