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`?
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. 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. 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. On Fri, Jun 9, 2017 at 05:24 Gor Gyolchanyan via swift-evolution < [email protected]> wrote: > Good point, but not necessarily. > 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. > 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. > > > On Jun 9, 2017, at 7:45 AM, Greg Parker <[email protected]> wrote: > > > On Jun 8, 2017, at 5:09 AM, Gor Gyolchanyan via swift-evolution < > [email protected]> wrote: > > 1. Arbitrary `self` Assignments In Intializers > > 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. > > > 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. > > > -- > Greg Parker [email protected] Runtime Wrangler > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
