[swift-evolution] [Proposal Draft] partial initializers

[Matthew Johnson]

> On Jan 20, 2016, at 5:29 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Jan 13, 2016, at 8:27, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> The compiler will absolutely, 100%, inescapably need to know which properties a given partial method initializes. Otherwise it can't properly perform its phase one check, and if this proposal breaks safe initialization, it's not going to be accepted.
>>> 
>>> We could specify that the compiler takes a peek at the implementation and figures out which fields it initializes, or we could specify that the method declares the fields it will initialize. But however we choose to do it, doing it in *some* way is not negotiable.
>> 
>> Yes of course it needs to know about what properties are initialized.  It does not need to know about which properties have been initialized prior to calling the partial initializer though if we don’t allow it to read pre-initialized properties.
> 
> I know there's a new thread now, but this is simply incorrect. Consider a struct with a single, non-optional AnyObject field:
> 
> struct Ref {
>   var referent: AnyObject
>   init func resetTo(newReferent: AnyObject) {
>     referent = newReferent
>   }
>   init(referent: AnyObject) {
>     resetTo.init(referent)
>   }
> }
> 
> If 'referent' has already been set, the assignment has to release the old object; if it hasn't, it must not touch that memory (which is presumably uninitialized).
> 
> I'm not sure if this practically affects the proposal in any way, other than making it a little harder to implement. But it's an important part of the model.

Thanks for catching this Jordan.  I was discussing requirements imposed by the partial initializer itself but of course any cleanup necessary must also happen and I didn’t fully consider that.

John asked that the proposal disallow redundant assignment to make implementation easier, which is included in the new draft.  I asked him whether this should apply to initial values for `var` properties but never got an answer.  I think the point you make indicates why he made the request which also indicates disallowing writing to a `var` with an initial value, which I currently allowed for in the proposal.  

I am open to modifying the proposal in whatever way the compiler team thinks is best.  :)  Feel free to respond with your thoughts in either thread.

Matthew

> 
> Best,
> Jordan
> 
> more comments coming on the other thread

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