[swift-evolution] [Proposal] Property behaviors

[Joe Groff]

> On Jan 20, 2016, at 9:48 AM, Matthew Johnson <musical.matthew at mac.com> wrote:
> 
>> 
>> On Jan 20, 2016, at 11:39 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> 
>>> On Jan 20, 2016, at 9:31 AM, Matthew Johnson <musical.matthew at mac.com <mailto:musical.matthew at mac.com>> wrote:
>>> 
>>> Joe, 
>>> 
>>> I’m wondering if you missed my comments.  I had a few questions I haven’t seen answered yet so I’m bumping them. 
>>> 
>>> -Matthew
>>> 
>>> The proposal makes it clear when an initializer is required but is a little bit less clear about when it may be left off.  Is this correct?
>>> 
>>> var [baseProp] x // no initializer, ok as long as base doesn't have init req?
>>> var [initializerReqt] y // no initializer, error because of the initializer requirement?
>> 
>> Sorry, I thought I explained this. The default stored property that gets instantiated for a base property can be initialized out-of-line, so the inline initializer expression is optional, yes.
>> 
>>> 
>>> Another thing that isn’t clear is what happens when a property with a behavior is set within the initializer of the containing type:
>>> 
>>> struct S {
>>>   var [observed] s: String
>>>   init(s: String) {
>>>     // What happens here?  Is the behavior’s “set” accessor called?  
>>>     // This may not always be desirable, as in the case of “observed"
>>>     self.s = s
>>>   }
>>> }
>> 
>> Just like today, assignments within the initializer would bypass the behavior and directly initialize the storage.
> 
> Thanks for clarifying.
> 
>> 
>>> 
>>> One thought is that it might be good to allow behaviors to have `init` accessor that is used if the property is assigned by an initializer of the containing type (only the first time the property is assigned).  This would clarify what happens during initialization of the containing type and allow for different init and set code paths when necessary.   It would be distinguished from the behavior initializer by the lack of parens.  If that is too subtle we could use a different name for the initialization accessor.
>> 
>> That's a possibility, but inserting initializer calls is a bit more heroic than what our current definite initialization implementation can do. That's not necessarily a showstopper, but it was a goal of the current design to avoid inserting accessor calls within inits at hard-to-predict places. (cc'ing ChrisL, to get his opinion on this as DI owner)
> 
> Makes sense.  Getting the behavior I would like to see out of a `phase2Immutable` behavior would definitely require updates to the DI rules.  I think the added safety makes it worth doing something in this area eventually, but it could be added later.  I’m interested to hear what Chris thinks.

I think it's important that delayed initialization also accommodate initialization *after* init() returns. There are many cases where full initialization depends on a process outside of init's control, especially in Cocoa with objects and outlets set up from nib files.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160120/404e7d11/attachment.html>