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@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
