Cool. I have reservations about idea #3, but we can tackle that another day. (Real life things beckon.) But suffice it to say that I now really, really like your idea #2.<br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 9, 2017 at 08:06 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com">gor@gyolchanyan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">You know, come to think of it, I totally agree, and here's why:<div>A normal initializer (if #2 is accepted) would *conceptually* have the signature:</div><div><br></div><div>mutating func `init`(...) -> Self</div><div><br></div><div>Which would mean that both `self` and the returned result are non-optional.</div><div>A failable initializer could then have the signature:</div><div><br></div><div>mutating func `init`() -> Self?</div><div><br></div><div>Which would make the returned result optional, but leave `self` non-optional.</div><div>This would make `return nil` less out-of-place, like you said, while still leaving `self` as a set-exactly-once `inout Self`.</div><div>A factory initializer would then have the signature:</div><div><br></div><div>static func `init`(...) -> Self</div><div><br></div><div>or in case of a failable factory initializer:</div><div><br></div><div>static func `init`(...) -> Self?</div><div><br></div><div>Which would still make sense with the now legal `return ...` syntax, while adding the restriction of not having any `self` at all.</div><div>So, annotating the initializer with the keyword `factory` would cause it to change the signature as well as remove any compiler assumptions about the dynamic type of the returned instance.</div><div><br></div><div>In addition, idea #3 would be available for more deterministic in-place initialization.</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br><blockquote type="cite"><div>On Jun 9, 2017, at 2:47 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-1696318748622386158Apple-interchange-newline"><div><div><div><div class="gmail_quote"><div>On Fri, Jun 9, 2017 at 07:33 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">So far, we've discussed two ways of interpreting `self = nil`, both of which have a sensible solution, in my opinion:<div><br></div><div>1. It's a special rule like you said, which can be seen as counter-intuitive, but recall that `return nil` is just as much of a special rule and is also largely counter-intuitive.</div></div></blockquote><div><br></div></div></div></div><div><div><div class="gmail_quote"><div>`return nil` is “special,” but it doesn’t conflict with any other syntax because the initializer notionally has no return value. Personally, I have always disliked `return nil` in failable initializers for that reason, but I couldn’t come up with a better alternative.</div><div><br></div><div>Your proposed idea to allow returning any value is interesting because, in the case of a failable initializer, `return nil` continues to have the same meaning if we consider the return value of the initializer to be of type `Self?`. For that reason, I think your idea #2 is quite clever, and it would go a long way in making `return nil` a lot less odd. It also increases the expressivity of initializers because it allows one to set the value of self and also return in one statement, clearly demonstrating the intention that no other code in the initializer should be run before returning.</div><div><br></div><div>For all of those reasons, I think idea #2 is a winning idea.</div></div></div></div><div><div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>The benefit of `self = nil` is that it's much more in line with initialization semantics, it provides more uniform syntax and it's a bit less restrictive.<br><div><br></div><div>2. It's an `inout Self!`, like Greg said, which can be seen as more cumbersome. Implicitly unwrapped optionals are a bit difficult, but this "variation" of it is much more restrictive then the normal ones, because unlike normal implicitly unwrapped optionals, this one cannot be accessed after being assigned nil (and it also cannot be indirectly assigned `nil`, because escaping `self` is not allowed before full initialization), so there is only one possible place it can be set to nil and that's directly in the initializer. This means that `self` can be safely treated as `inout Self` before being set to nil (and after being set to nil, it doesn't matter any more because you aren't allowed to access it, due to not being fully initialized).</div></div></div></blockquote><div><br></div><div>I have to say, I don’t like either of these explanations at all. I think having a “special” IUO is a difficult sell; it is just conceptually too complicated, and I don’t agree that it gains you much.</div><div><br></div><div>By your own admission, `self = nil` is wonky, and making the language wonkier because it currently has a parallel wonky feature in `return nil` seems like the wrong way to go. In addition, there’s nothing gained here that cannot be done with a defer statement; of course, defer statements might not be very elegant, but it would certainly be less wonky than inventing a new variation on an IUO to allow assignment of nil to self... For those reasons, I conclude that I’m not excited about your idea #1.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div></div><div>Overall, I'd go with #2 because it involves much less confusing magic and the restrictions of `self as inout Self!` are imposed by already existing and well-understood initialization logic, so the provided guarantees don't really come at the cost of much clarity.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br><blockquote type="cite"><div>On Jun 9, 2017, at 2:23 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784Apple-interchange-newline"><div><div><br><div class="gmail_quote"><div>On Fri, Jun 9, 2017 at 07:12 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">I think a good approach would be to have `self = nil` only mean `the initializer is going to fail` because if your type is ExpressibleByNilLiteral, it means that the `nil` of your type already carries the same meaning as if your type was not ExpressibleByNilLiteral and was an optional instead, so having a failable initializer doesn't really make sense in that case (since you could've initialized `self` to its own `nil` in case of failure). Still, some valid use cases may exist, so the natural (and quite intuitive) way to circumvent this would be to call `self.init(nilLiteral: ())` directly.</div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div></div></div></div></div></blockquote><div><br></div><div>So you would create a special rule that `self = nil` means a different thing in an initializer than it does in a function? Essentially, then, you’re creating your own variation on an implicitly unwrapped optional, where `self` is of type `inout Self?` for assignment in initializers only but not for any other purpose. Implicitly unwrapped optionals are hard to reason about, and having a variation on it would be even harder to understand. I don’t think this is a workable design.</div><div><br></div><div>It might be possible to have `self` be of type `inout Self?`; however, I do think Greg is right that it would create more boilerplate than the current situation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><div><blockquote type="cite"><div>On Jun 9, 2017, at 2:07 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-interchange-newline"><div><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-interchange-newline">On Fri, Jun 9, 2017 at 06:56 Gor Gyolchanyan <<a href="mailto:gor@gyolchanyan.com" target="_blank">gor@gyolchanyan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>The type of `self` could remain `inout Self` inside the failable initializer. The ability to assign nil would be a compiler magic (much like `return nil` is compiler magic) that is meant to introduce uniformity to the initialization logic.</div><br><div>The idea is to define all different ways initialization can take place and expand them to be used uniformly on both `self` and all its members, as well as remove the ways that do not make sense for their purpose.</div><div><br></div><div>Currently, there are 3 ways of initializing self as a whole:</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>1. delegating initializer</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>2. assigning to self</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>3. returning nil</div><div><div><br></div><div>#1: The delegating initializer is pretty much perfect at this point, in my opinion, so no changes there.</div><div><br></div><div>#2: The only exception in assigning to self is the `nil` inside failable initializers.</div><div><br></div><div>#3: The only thing that can be returned from an initializer is `nil`, which is compiler magic, so we can thing of it as a misnomer (because we aren't really **returning** anything).</div><div><br></div><div>If, for a second, we forget about potential factory initializers, returning anything from an initializer doesn't make much sense, because an initializer is conceptually meant to bring an existing object in memory to a type-specific valid state. This semantic was very explicitly in Objective-C with `[[MyType alloc] init]`. Especially since even syntactically, the initializer does not specify any return type, the idea of returning from an initializer is counter-intuitive both syntactically and semantically.</div><div><br></div><div>The actual *behavior* of `return nil` is very sensible, so the behavior, I imagine `self = nil`, would largely mean the same (except not needed to return immediately and allowing non-self-accessing code to be executed before return). Being able to assign `nil` to a non-optional (ExpressibleByNilLiteral doesn't count) may feel a bit wonky,</div></div></div></blockquote><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">What happens when Self is ExpressibleByNilLiteral and you want to initialize self to nil? That is what `self = nil` means if `self` is of type `inout Self`. If `self` is of type `inout Self` and Self is not ExpressibleByNilLiteral, then it must be an error to assign nil to self. Anything else does not make sense, unless `self` is of type `inout Self?`.</div><div style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><blockquote class="gmail_quote" style="font-family:DejaVuSans;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>but not as wonky as returning nil from something that is meant to initialize an object in-place and doesn't look like it should return anything.</div><div><br></div><div># Factory Initializers</div><div><br></div><div>In case of factory initializers, the much discussed `factory init` syntax could completely flip this logic, but making the initializer essentially a static function that returns an object. In this case the initializer could be made to specify the return type (that is the supertype of all possible factory-created objects) and assigning to self would be forbidden because there is not self yet:</div><div><br></div><div>extension MyProtocol {</div><div><br></div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>public factory init(weCool: Bool) -> MyProtocol {</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>self = MyImpl() // error: cannot assign to `self` in a factory initializer</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>self.init(...) // error: cannot make a delegating initializer call in a factory initializer</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>if weCool {</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>return MyCoolImpl()</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>} else {</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>return MyUncoolImpl()</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div><span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div><br></div><div>}</div><div><br></div><div># In-place Member Initializers</div><div><br></div><div>In addition, member initialization currently is only possible with #2 (as in `self.member = value`), which could be extended in a non-factory initializer to be initializable in-place like this:</div><div><br></div><div>self.member.init(...)</div><div><br></div><div>This would compliment the delegating initialization syntax, while giving a more reliable performance guarantee that this member will not be copy-initialized.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br><blockquote type="cite"><div>On Jun 9, 2017, at 1:32 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922Apple-interchange-newline"><div>If `self` is not of type `inout Self?`, then what is the type of `self` such that you may assign it a value of `nil`?<br><br>It certainly cannot be of type `inout Self`, unless `Self` conforms to `ExpressibleByNilLiteral`, in which case you are able to assign `self = nil` an unlimited number of times–but that has a totally different meaning.<br><br>Could `self` be of type `inout Self!`? Now that implicitly unwrapped optionals are no longer their own type, I’m not sure that’s possible. But even if it were, that seems unintuitive and potentially error-prone.<br><br>So I think Greg is quite right that, to enable this feature, `self` would have to be of type `inout Self?`–which is intriguing but potentially more boilerplatey than the status quo.<br><div class="gmail_quote"><div>On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Good point, but not necessarily.<br><div>Since you cannot access `self` before it being fully initialized and since `self` can only be initialized once, this would mean that after `self = nil`, you won't be allowed to access `self` in your initializer at all.You'll be able to do any potential, cleanup though.</div><div>Also, since there can be only one `self = nil`, there's no reason to treat `self` as `inout Self?`, because the only place it can be `nil` is the place it cannot be accessed any more.</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><div><br><blockquote type="cite"><div>On Jun 9, 2017, at 7:45 AM, Greg Parker <<a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a>> wrote:</div><br class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182m_-8492261585337030922m_1716065582357142928Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div><br>1. Arbitrary `self` Assignments In Intializers<br><br>The first ideas is to allow `self = nil` inside failable initializers (essentially making `self` look like `inout Self?` instead of `inout Self` with magical `return nil`), so that all initializers uniformly can be written in `self = ...` form for clarity and convenience purposes. This should, theoretically, be nothing but a `defer { return nil }` type of rewrite, so I don't see any major difficulties implementing this. This is especially useful for failable-initializing enums where the main switch simply assigns to self in all cases and the rest of the initializer does some post-processing.<br></div></div></blockquote><div><br></div><div>I don't see how to avoid source incompatibility and uglification of failable initializer implementations here. Allowing `self = nil` inside a failable initializer would require `self` to be an optional. That in turn would require every use of `self` in the initializer to be nil-checked or forced. I don't think that loss everywhere outweighs the gain of `self = nil` in some places.</div></div><br><div><br></div><div>-- </div><div>Greg Parker <span class="m_-1696318748622386158m_-1836007598760388288m_758143498405985784m_8163076293838887182Apple-converted-space"> </span><a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a> Runtime Wrangler</div><div><br></div><div><br></div></div></div></blockquote></div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></div></blockquote></div></div></div></blockquote></div></blockquote></div><br></div></div></div></blockquote></div></div>
</div></blockquote></div><br></div></div></blockquote></div></div></div>
</div></blockquote></div><br></div></div></blockquote></div>