Wouldn't calling the NSDate constructor escape the context ?
Sent from Supmenow.com
On Fri, Apr 29, 2016 at 1:47 PM -0700, "Tod Cunningham via swift-evolution"
<swift-evolution@swift.org> wrote:
Adrian, excellent example of a challenging case. I would say that when calling
any method that might mutate the value, the compiler would no longer be able to
safely auto unwrap. That really limits the usefulness of this capability, at
least for classes. For classes that would mean any call that would leave the
current context would disable the auto unwrapping. For structs, it would be any
mutating method would disable the auto unwrap.
I modified my example a bit to show how this would effect the ability to auto
unwrap.
class Test {
var today: NSDate? = nil
func test() {
today = today ?? NSDate()
let timeInterval: NSTimeInterval = today.timeIntervalSinceNow // No !
required (auto unwrapped)
// today can no longer be auto unwrapped as calling timeIntervalSinceNow
has escaped
// the enclosing context and could cause side effects with this instance.
}
It would be nice if the compiler could know that timeIntervalSinceNow had no
dependencies or knowledge of class Test, but I doubt that would be practical.
However if Test was a struct the mutation information is readily available, so
we know these calls would be safe:
struct Test {
var today: NSDate? = nil
mutating func test() {
today = today ?? NSDate()
let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow // No !
required (auto unwrapped)
let timeInterval2: NSTimeInterval = today!.timeIntervalSinceNow //
Explicit unwrapping would still be allowed
print("Today is \(today)") // Would be printed as a value (not an
optional)
// today can still be auto unwrapped as it won't be mutated by
timeIntervalSinceNow or print
}
}
From: > on behalf of Adrian Zubarev via swift-evolution >
Reply-To: Adrian Zubarev >
Date: Friday, April 29, 2016 at 3:21 PM
To: "swift-evolution@swift.org" >
Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
+1 But your example is too good to be true. :)
What would happen to this code:
class A {
var value: Type? = nil
func reset() { self.value = nil }
func test() {
self.value = self.value ?? Type()
self.reset()
self.value.doSomething()
// can the compiler be sure that our value wasn't reset somewhere from
a different scope ?
}
}
I'm curious what will happen here. Can someone clarify on that?
--
Adrian Zubarev
Am 29. April 2016 um 16:37:37, Tod Cunningham via swift-evolution
(swift-evolution@swift.org) schrieb:
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
