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