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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
