The problem is, it's not clear what assumptions the swift compiler may have on the semantics of initializers. There may be aggressive optimizations going on under the hood with the knowledge that the returned type is the static type that is being initialized. This guaranteed lack of polymorphism might be used to do things like in-place initialization when assigning to a variable or stuff like that. Factory initializers would break that logic and would require some additional compiler awareness, so as much as I'd love to have factory initializers, It doesn't look like it's as easy as adding syntax for it.
> On Jun 8, 2017, at 6:53 PM, Adrian Zubarev <[email protected]> > wrote: > > Well I was referring to the title of (1) not to the addition it creates with > failable initializers, which I guess is fine by me, but I’d need a more > detailed proposal or draft to provide better feedback though. > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 8. Juni 2017 um 17:51:28, Gor Gyolchanyan ([email protected] > <mailto:[email protected]>) schrieb: > >> 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] >>> <mailto:[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
