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] <mailto:[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] <mailto:[email protected]> Runtime > Wrangler > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
