> On Jul 1, 2015, at 5:39 PM, Rick Mann <[email protected]> wrote:
>
>> On Jul 1, 2015, at 17:04 , Greg Parker <[email protected]> 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 protected] Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
