<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">No, but you can declare it as:</div><div class=""><br class=""></div><div class="">lazy var myStateDerivedProperty: Int = self.myStateManager.property</div><div class=""><br class=""></div><div class="">Of course, there are still more complex scenarious that require IUOs. For example anything that gets loaded from the UI (currently marked as @IBOutlet). IUOs are definitely useful for items that will be nonnil 99% of the object's lifetime, but don't necessarily need to be 100% of the time.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 4, 2017, at 6:22 PM, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Dependency Injection does sort out this case, you're right.</div><div class=""><br class=""></div><div class="">One case it doesn't fix is where your initialised value depends on something within your superclass to be created first to derive your initialising value.</div><div class=""><br class=""></div><div class="">class MyBaseClass {</div><div class=""> let myStateManager: StateManager</div><div class=""><br class=""></div><div class=""> init() {</div><div class=""> // sets up stateManager</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">class MySubclass: MyBaseClass {</div><div class=""> var myStateDerivedProperty: Int!</div><div class=""><br class=""></div><div class=""> override init() {</div><div class=""> super.init()</div><div class=""><br class=""></div><div class=""> myStateDerivedProperty = // derive state from myStateManager</div><div class=""> }</div><div class="">}</div><div class=""><br class="">In this case, the writer cannot initialise their state derived properties until the superclass has completed its initialization because it is waiting on the stateManager to derive its initial state.</div><div class=""><br class=""></div><div class="">This is a somewhat contrived example but I've actually found myself with similar patterns where I use other frameworks, where the default is either not defined in documentation or the object I require as part of initialising the property does not exist until after the initialisation.</div><div class=""><br class=""></div><div class="">Rod</div><div class=""><br class="">On 5 Feb 2017, at 4:04 am, Jean-Daniel <<a href="mailto:mailing@xenonium.com" class="">mailing@xenonium.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 4 févr. 2017 à 16:52, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Joe,</div><div class=""><br class=""></div><div class="">I think this comes back to the idea that a lot of people in the wider Swift community hold that Implicitly Unwrapped Optionals are “bad” and “discouraged", and therefore shouldn’t be used. There seems to have been much pushback on Implicitly Unwrapped Optionals in the Swift 3 timeframe, to try and remove them as much as possible.</div><div class=""><br class=""></div><div class="">I definitely see this as a valuable use for them. While an integer is an extremely lightweight example of this, when it could include creating entire object graphs multiple times due to initialiser behaviour, or because you won’t know the correct state of a variable until *after* initialisation has occurred on the superclass, this is a valuable example where IUOs are really the only alternative for performance or correctness reasons.</div></div></div></blockquote><div class=""><br class=""></div><div class="">IUO are useful to workaround poorly designed class. As already said, you example could be rewrite like follow to avoid any useless computation</div><div class=""><br class=""></div><div class="">class A {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let x: Int</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init(_ x: Int = 3) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>self.x = x</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">class B : A {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>override init() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super.init(1)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">No useless initialization of x, and no need to use IUO. Is it a suffisent reason to keep them in the language ? Anyway, as long as we need them to usefully use IBOutlet, I’m pretty sure they are not going anywhere.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Perhaps this is an area where the Swift Core Team could provide guidance to the community? Do the Core Team see IUOs as “bad” outright, and destined to go away when possible, or are they a tool with specific uses that look to be supported into the future?</div><div class=""><br class=""></div><div class="">- Rod</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 4 Feb 2017, at 5:40 am, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 31, 2017, at 3:52 AM, Victor Petrescu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">4. Joe Groff says there is already a backdoor of sorts ("There already is a backdoor of sorts. This is one of the intended use cases for implicitly-unwrapped optionals. If you don't want to be hassled by DI, declare a property as T! type, and it will be implicitly initialized to nil, and trap if you try to use it as an unwrapped T without initializing it first."): I'm assuming by T you mean generics. If that is true that may already solve the problem but... generics are a new concept for me (first time I really encountered and used them is now, in swift) but to my understanding their role is to deal with cases you don't know the type. Can you please show how to use this to work around the posted issue?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Sidenote: There may be another workaround using optionals (Joe Groff answer made it pop in my mind) but... I know the type and value for the variable, it is not optional or nil. Unwrapping each time someone needs it does not look like the best solution to me.</span></div></blockquote></div><br class=""><div class="">You don't need to understand generics to use implicitly-unwrapped optionals. By `T!` I was referring to the syntax used to represent them; you would write Int! or String! or whatever in your code. For your example, this would let you avoid having to invoke super.init() before resetting `x`:</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class="">class A {<br class=""></div> var x:Int! // Int! is nil by default<br class="">}</div></div><div class=""><div class=""><div class=""><br class=""></div><div class="">class B : A {<br class=""></div><div class=""> override init() {<br class=""></div><div class=""> x = 2 // So we can set it here w/o super.init first</div><div class=""> }<br class=""></div><div class="">}</div></div></div></div><div class=""><br class=""></div><div class="">print(B().x + 1) // and we don't need to explicitly unwrap it to use it, unlike `Int?`</div><div class=""><br class=""></div><div class="">You're giving up the static guarantee that `x` has a value, so you'll get a runtime error if you try to use it before it's initialized, but that's the same situation you have in Java, where dereferencing an uninitialized object reference gives an NPE. Whether you want the hard guarantee that `x` is never optional from the compiler, or the convenience of leaving that up to runtime checks, is a call you have to make; Swift defaults to the strong guarantee, but implicitly-unwrapped optional types like Int! are intended to give you an out if the static model is too strict or inefficient.</div><div class=""><br class=""></div><div class="">-Joe</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>