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 dir="ltr">On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</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">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_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 <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><br>
</blockquote></div>