[swift-evolution] [Proposal] Property behaviors

[Matthew Johnson]

Sent from my iPad

> On Dec 17, 2015, at 7:05 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> On Dec 17, 2015, at 4:36 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>  
>>> It looks to me that the only benefit this has versus IOUs is you can use a `let` instead of a `var`. It's worth pointing out that this actually doesn't even replace IOUs for @IBOutlets because it's commonly useful to use optional-chaining on outlets for code that might run before the view is loaded (and while optional chaining is possible with behavior access, it's a lot more awkward).
>> 
>> There are several advantages over IUO that I see. The behavior can ensure that a mutable delayed var never gets reset to nil, and can dynamically enforce that an immutable delayed var/let isn't reset after it's been initialized. It also communicates intent; as I mentioned to Matthew in another subthread, 
> 
> Another benefit is that this allows elimination of an entire use-case for IOUs.  This makes it more appetizing and possible to push IOUs further off into a corner.  I’m personally interested in the idea of IOUs evolving into something that isn’t a first class type - instead they could only exist in argument and return types.  Eliminating a common reason that people use them for properties would help with that.

+1 to this.  Anything that replaces potentially unsafe patterns with safer patterns is a step in the right direction.  That's why I think it's so important to have compiler support for delayed properties one way or another.

Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/0835373e/attachment.html>