[swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown]

I agree that it's a pain to have to unwrap after this, but this proposal worries me somewhat.

I don't think we can safely guarantee that the value is non-null outside a very limited subset of cases, and we're breaking the simple, general and reasonable syntax of Swift for a very minor convenience win. 

Additionally, this will play out like magic. Suddenly an optional starts dynamically changing its behaviour. I can't see where the compiler begins or ends the assertion of the value's non-null state, and so you have code that, with a little shifting around, begins to fail to even compile, based on something the user cannot see.

I think we have better mechanisms to handle this type of thing, like the if/guard let syntax, and implicitly unwrapped optionals.

> On 30 Apr 2016, at 12:37 AM, Tod Cunningham via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm new to the swift evolution community, but I wanted to toss an idea out there to get some feedback on it. So here it goes...
> 
> Currently, if you assign a non-nil value to an optional and then want to access that optional later, in the same context, you need to manually unwrap the value.  This is usually done either by using "!" or by using something like "if let" or guard.
> 
> What would it be like if the compiler could auto unwrap, in cases where in knows the optional will have some value?  This would make the code "clean" and still be safe.
> 
> This concept of Auto Unwrapping of Optionals is similar to Implicitly Unwrapped Optionals, but is only applied when the compiler knows it is safe to do so.
> 
> Take the following example:
> 
> class Test {
>    var today: NSDate? = nil
>    func test() {
>        today = today ?? NSDate()
>        print("Today is \(today)")   // Would be printed as an optional
>        let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow  // Requires ! or (if let) to unwrap
>        // ... do stuff with timeInterval ...
>    }
> }
> 
> With the above example, the compiler could known that today has a value after it's set in the test method.  So why couldn't the compiler auto unwrap it when accessed?  This would mean manual unwrapping would be unnecessary:
> 
> class Test {
>    var today: NSDate? = nil
>    func test() {
>        today = today ?? NSDate()
>        print("Today is \(today)")   // Would be printed as a value (not an optional)
>        let timeInterval: NSTimeInterval = today.timeIntervalSinceNow  // No ! required (auto unwrapped)
>        // ... do stuff with timeInterval ...
>    }
> }
> 
> If the value later gets set to an optional value, then it will no longer be auto unwrapable :
> 
> class Test {
>    var today: NSDate? = nil
> 
>    func optionalDay() -> NSDate? {
>        return NSDate()
>    }
> 
>    func test() {
>        today = today ?? NSDate()
>        print("Today is \(today)")   // Would be printed as a value (not an optional)
>        let timeInterval: NSTimeInterval = today.timeIntervalSinceNow    // No ! required (auto unwrapped)
>        let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow  // Explicit unwrapping would still be allowed
> 
>        // If today is assigned an optional value, we can no longer auto unwrap it
>        today = optionalDay()
>        print("Today is \(today)")   // Would be printed as an optional
>        let timeInterval3: NSTimeInterval = today!.timeIntervalSinceNow  // manual unwrapping would be required
>    }
> }
> 
> Note in the above example, explicit unwrapping would still be allow.  The variable is still an optional.  This allows for existing code to remain unchanged.
> 
> This change would encourage less use of forced unwrapping "!", generally require the developer to write less code, and would maintain code safety.  On the down side, it is performing some compiler “magic”.  It would be yet another thing to explain when trying to introduce people to swift and especially optionals.
> 
> What do you all think, would something like this be worth pursuing, what other pluses or minus would this introduce, has something like this already been discussed?
> 
> Thanks,
> Tod Cunningham
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution