IUO type, treat nil as normal error, not fatal error

Evolution Discussion
1

Hi all,

I want to discuss the Implicitly Unwrapped Optional Type.

In Swift 1 and Swift2, when a variable declared as IUO type, its value should be non-nil.
If its value is nil, it will crash the program when read the value.

I believe it is better to let developer catch this event, treat it as normal error, and can be caught.

Thanks!

Jiannan

2

I think it would be an interesting to have an optional type that has throwing semantics on errors (I wonder if the behaviors proposal would allow something like that), but IMHO this should be something else than IUO.

IUO is great for when you’re pretty darn sure a thing will never actually be nil on access, but can’t be statically guaranteed on initialization (e.g. @IBOutlets). Making it throw instead of crash would be annoying — worse than just using a regular optional — because you’d have to wrap every use in `do { try … }`

— Radek

···

On 30 Mar 2016, at 13:24, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I want to discuss the Implicitly Unwrapped Optional Type.

In Swift 1 and Swift2, when a variable declared as IUO type, its value should be non-nil.
If its value is nil, it will crash the program when read the value.

I believe it is better to let developer catch this event, treat it as normal error, and can be caught.

Thanks!

Jiannan

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution