[swift-evolution] [Discussion]: Deprecate !-Unwrapping of Optionals

Dave Abrahams dabrahams at apple.com
Mon Feb 29 16:53:23 CST 2016


on Mon Feb 29 2016, Jacob Bandes-Storch <swift-evolution at swift.org> wrote:

> unsafeUnwrap already exists, though with a slightly different meaning (no
> check is performed in -O builds).  I think it may be turning into an
> "unsafelyUnwrapped" property in the future.
>
> Generally I'm +1 on this. I do share others' concerns about things like
> playgrounds and xibs.
>
> I suppose the existence of xibs requires us to keep the
> ImplicitlyUnwrappedOptional type if we don't want to require people use "if
> let" *everywhere*, unless we somehow move the setting of IBOutlets into a
> special throwing initializer.
>
> For writing quick code in playgrounds, something like ".unsafelyUnwrapped"
> is probably fine, if a bit wordy. Or if, as Dave Sweeris suggests, you make
> "unwrap() throws", then playgrounds can just use "try! x.unwrap()" for
> unwrapping. (Or did you want to propose removing try! too?)

The problem with making unwrap() throws is that throwing is for
recoverable errors, but the intended use case for "!" is for situations
where it would be a program bug if unwrapping failed, and bugs are not
recoverable.

> Jacob
>
> On Mon, Feb 29, 2016 at 1:26 PM, Developer via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I was thinking something more like
>>
>> func unsafeUnwrap<T>(opt : Optional<T>) -> T {
>>     switch opt {
>>         case let .Some(val):
>>             return val
>>         default:
>>              fatalError("Unexpectedly found nil while unwrapping optional
>> value")
>>     }
>> }
>>
>> Bang doesn't go away, it just becomes more obvious that you're making a
>> leap of logic (as it were).
>>
>> ~Robert Widmann
>>
>> 2016/02/29 15:59、davesweeris at mac.com のメッセージ:
>>
>>
>> On Feb 29, 2016, at 2:24 PM, Developer via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> And for those cases there will be a standard library function or something
>> more obvious than bang to make up for the deprecated operator.  Force
>> unwrapping will not go away (that's a terribly unproductive idea), but the
>> goal is to make a dangerous operation more obvious[ly dangerous].
>>
>>
>> Like this?
>> enum OptionalUnwrappingError : ErrorType {
>>     case unexpectedlyFoundNil
>> }
>> enum Optional<T> {
>>     typealias Wrapped = T
>>     case None
>>     case Some(Wrapped)
>>     ...
>>     func unwrap() throws -> Wrapped {
>>         switch self {
>>         case .None: throw OptionalError.unexpectedlyFoundNil
>>         case .Some(let value): return value
>>         }
>>     }
>> }
>>
>> It’s hard to get more obvious than the compiler complaining that you
>> haven’t wrapped a throwing function in a try block
>>
>> - Dave Sweeris
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave



More information about the swift-evolution mailing list