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
