I think the programmer knows best in a case like that. If I know it has a valid value, I wouldn't use an optional:
class Test { var today: NSDate? = nil func test() { let today = self.today ?? NSDate() self.today = today print("Today is \(today)") // Would not be printed as an optional let timeInterval: NSTimeInterval = today.timeIntervalSinceNow } } What do you think about that? > 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution