This is definitely something I’m hoping to see as well, alongside more
intelligent handling of the is keyword, as currently Swift doesn’t handle the
following either:
if foo is SomeType { /* foo could be safely used as SomeType here, but
currently is not */ }
Hopefully someone more familiar can weigh in, as it seems like something I
expect to be on the way but perhaps has been delayed in case any further
changes to the type system were required?
> On 29 Apr 2016, at 15:37, Tod Cunningham via swift-evolution
> <swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
