Not exactly. #1 is an addition to the language syntax. It's simply a convenient way of expressing failure in a failable initializer the logic of which is already implemented, while extending the syntax in a way that would require zero effort to enable a potential factory initializers.
> On Jun 8, 2017, at 6:45 PM, Adrian Zubarev <[email protected]> > wrote: > > Isn’t 1 und 2.1 almost the same stuff? I’ve asked once if there is a chance > for Swift to support init(_ other: Self) { self = other } for classes. Joe > Groff replied this is called “factory initializer”. > > This feature is highly needed for all the iOS developers out there who abuse > NIBs and create a custom UIView in a nib file then instead of assigning it to > a UIViewController they nest it in another container view, which is not what > it’s meant for in the first place. Factory initializer could solve this issue > by simply assigning the instance created from a nib file to self. The nested > view hierarchy would disappear and it won’t be that much of an abuse anymore. > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 8. Juni 2017 um 14:09:30, Gor Gyolchanyan via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> 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? >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
