No, but you can declare it as:
lazy var myStateDerivedProperty: Int = self.myStateManager.property
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.
> On Feb 4, 2017, at 6:22 PM, Rod Brown via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Dependency Injection does sort out this case, you're right.
>
> 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.
>
> class MyBaseClass {
> let myStateManager: StateManager
>
> init() {
> // sets up stateManager
> }
> }
>
> class MySubclass: MyBaseClass {
> var myStateDerivedProperty: Int!
>
> override init() {
> super.init()
>
> myStateDerivedProperty = // derive state from myStateManager
> }
> }
>
> 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.
>
> 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.
>
> Rod
>
> On 5 Feb 2017, at 4:04 am, Jean-Daniel <mail...@xenonium.com
> <mailto:mail...@xenonium.com>> wrote:
>
>>
>>> Le 4 févr. 2017 à 16:52, Rod Brown via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>
>>> Hi Joe,
>>>
>>> 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.
>>>
>>> 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.
>>
>> IUO are useful to workaround poorly designed class. As already said, you
>> example could be rewrite like follow to avoid any useless computation
>>
>> class A {
>> let x: Int
>> init(_ x: Int = 3) {
>> self.x = x
>> }
>> }
>>
>> class B : A {
>> override init() {
>> …
>> super.init(1)
>> }
>> }
>>
>> 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.
>>
>>
>>>
>>> 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?
>>>
>>> - Rod
>>>
>>>
>>>
>>>> On 4 Feb 2017, at 5:40 am, Joe Groff via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>>
>>>>> On Jan 31, 2017, at 3:52 AM, Victor Petrescu via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> 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?
>>>>>
>>>>> 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.
>>>>
>>>> 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`:
>>>>
>>>> class A {
>>>> var x:Int! // Int! is nil by default
>>>> }
>>>>
>>>> class B : A {
>>>> override init() {
>>>> x = 2 // So we can set it here w/o super.init first
>>>> }
>>>> }
>>>>
>>>> print(B().x + 1) // and we don't need to explicitly unwrap it to use it,
>>>> unlike `Int?`
>>>>
>>>> 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.
>>>>
>>>> -Joe
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
