> On Jun 8, 2017, at 05:09, Gor Gyolchanyan via swift-evolution > <[email protected]> wrote: > > Disclaimer: I do realize that any of the following ideas may have been > discussed before and/or there might be a good reason for their lack of > implementation, so please go easy in me. 🙂 > > 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. > > 2. Arbitrary `return` Statements In Intializers > > The second idea is to allow `return ...` inside all initializers, which > should also, theoretically, be a simple rewrite to `self = ...; return`. This > one is to complement the existing `return nil` and allow some super-short > initializers with a switch that returns in all cases or a more complex > initializer that has a lot of guard statements. > > 2.1. Future Factory Initializers > > In addition, the `return ...` syntax has the benefit for potential factory > initializers. So far, the proposals for factory initializers involved a > keyword attached to the initializer, which just complicates the lexical > structure of the language and adds unnecessary complication to the interface > of types. Currently, factory initializers imported from Objective-C or from C > using the `__attribute__((swift_name("MyType.init(self:...)")))` look like > normal initializers (an in case of C, the return value doesn't even have to > be related to the enclosing type in any way), but behave as you'd expect: you > call the initializer and the result is a value that *should* be a subtype of > the type you've called the initializer for. So, if in the future Swift gets > native factory initializers (including, most importantly, in protocols), it > won't require special syntax, because simply returning an instance of a > subtype (with a compile-time check, of course) would look and behave very > intuitively. This would also be very useful for singletons, which would use a > private initializer for creating the instance and a public factory > initializer for returning it. > > 3. Failable Member Initialization > > The third idea is to allow writing `self.member = MemberType?(...)` or > `self.member = .init?(...)` (the exact syntax is up to debate) inside > failable initializers, which would be simply rewritten as: > > guard let _self_member = MemberType(...) else { > return nil > } > self.member = _self_member > > This will dramatically reduce the boilerplate and visual clutter form complex > failable initializers that call other failable initializers. A good use case > would be complex `LosslessStringConvertible` types with many > `LosslessStringConvertible` members. > > So, what do you guys think?
#1 & #3 would violate Swift's rule about having to fully initialize all properties in inits. My initial reaction is to like #2, though, assuming I understand it correctly. - Dave Sweeris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
