Re: Swift 2 throws from init()
Re: Swift 2 throws from init()
- Subject: Re: Swift 2 throws from init()
- From: Greg Parker <email@hidden>
- Date: Wed, 01 Jul 2015 18:15:25 -0700
> On Jul 1, 2015, at 5:39 PM, Rick Mann <email@hidden> wrote:
>
>> On Jul 1, 2015, at 17:04 , Greg Parker <email@hidden> wrote:
>>
>> Implicitly unwrapped optional is a good solution for this. The source code is no more complicated outside init, and if you get something wrong then you will get a runtime error with a useful message.
>
> All that makes sense, although Jens's answer confuses things a bit ("According to Chris Lattner (on the swift-language mailing list) this is a known problem in the current compiler and will be fixed.").
I described the current model. We would like to improve that model, but (as Chris said) we have a lot of competing demands for compiler engineer-hours.
> What's the run-time penalty of using implicitly- or force-unwrapped Optionals? Does it do a check for null at each invocation, or does it crash?
A forced unwrap generates code of the form `if x == nil { halt with error "value is unexpectedly nil" }`. The CPU's branch predictor will make it run fast, so the biggest cost is the increased code size. (And sometimes an increased object instance size, in the cases where Optional<T> is bigger than T alone. For pointer types and some other types the compiler is smart enough to compact Optional<T> into the same size storage as T.)
An implicitly-unwrapped optional works as if every access were force-unwrapped. I don't know how well the optimizer can fold redundant nil checks together; it's likely that there are cases that would be a little bit faster when written by hand with a single unwrap.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden