Can't see any significant extra overhead because of implicity unwrapped
property for your code. Could you clarify?
As for "going away" - as I understand, just ImplicitlyUnwrappedOptional
type itself will be removed, but not the "implicitly unwrapped" feature:
"Appending ! to the type of a Swift declaration will give it optional type
and annotate the declaration with an attribute stating that it may be
implicitly unwrapped when used."
So I still think right now the solution for your issue is implicitly
unwrapped optional. But again, I 100% support the idea of "defer init",
more specifically the idea of explicitly called "defer init" in other
inits, if "defer init()" is defined.
On 29.04.2016 3:49, David Sweeris wrote:
On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution
<swift-evolution@swift.org> wrote:
I think I like this idea. It is clear that it is init() and 'defer' says that
it is called at the end of each init. IMO we need exactly some kind of 'init'
as only in init we can set un-initialized stored properties.
But, why implicitly unwrapped optionals are not solution here? I.e.
To avoid the extra overhead. Also, they’re sorta going away in Swift 3:
https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
- Dave Sweeris.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
