[swift-evolution] Auto Unwrapping Of Optionals

[Cristián Arenas Ulloa via swift-evolution]

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Josh Parmenter via swift-evolution]

yes - that is a wonderful syntax addition in my opinion.
Josh

> On May 2, 2016, at 2:08 PM, Tod Cunningham via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> +1 on the shadow variable idea.  What an awesome idea.
> 
> - Tod
> 
> 
> 
> 
> 
> On 5/2/16, 4:41 PM, "Rod Brown" <rodney.bro...@icloud.com> wrote:
> 
>> Wow, I'm really sad I missed this while I was writing my last response!
>> 
>> I completely agree with this, and that is a much better solution than the 
>> ones previously suggested.
>> 
>> - Rod
>> 
>> 
>>> On 3 May 2016, at 6:16 AM, David Waite <da...@alkaline-solutions.com> wrote:
>>> 
>>> It is a bad idea to have the compiler change the interpretation of a type 
>>> without some hard and fast rules; the compiler’s interpretation of the 
>>> optionality of your code will result in your code being legal or not.
>>> 
>>> In terms of solutions, I would prefer something similar to a guard 
>>> statement that, rather than exiting, shadows a constant or variable with a 
>>> non-optional equivalent type, e.g.
>>> 
>>> shadow var today = today ?? NSDate()
>>> let timeInterval = today.timeIntervalSinceNow
>>> 
>>> -DW
>>> 
>>>> On May 2, 2016, at 1:27 PM, Tod Cunningham via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> "I wonder if we’re pushing down the road of convenience at the expense of 
>>>> truth. The if/guard let syntax is clear that you’re getting a separate 
>>>> reference or copy, but what you’re suggesting is hiding the reality from 
>>>> the user for what I see as relatively little convenience."
>>>> 
>>>> It just might be me trying to avoid using !, and especially avoid implicit 
>>>> unwrapped options.  While there is nothing wrong with the following code 
>>>> it makes me very uncomfortable from a defensive programming point of view:
>>>> 
>>>>  today = today ?? NSDate()
>>>>  let timeInterval = today!.timeIntervalSinceNow
>>>> 
>>>> Some developer coming along and changing the code could easily introduce a 
>>>> crash, such as by removing the default value.  In the above example, such 
>>>> a change wouldn’t introduce a compiler warning/error and the bug might not 
>>>> reveal itself until a much later.
>>>> 
>>>> Also using if-let or guard also doesn’t seem right, in this case, as it 
>>>> should never fail:
>>>> 
>>>> today = today ?? NSDate()   // self.today changed!
>>>> if let today = today {
>>>>let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>>> } else {
>>>>assertFailure()
>>>> }
>>>> 
>>>> Same issue with guard:
>>>> 
>>>> today = today ?? NSDate()   // self.today changed!
>>>> guard let today = today else {
>>>>assertFailure()
>>>>return //  that should never happen
>>>> }
>>>> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>>> 
>>>> This introduces code that just gets in the way of the code’s meaning for 
>>>> cases that should never happen.  Yuck, there has to be a better way!
>>>> 
>>>> - Tod
>>>> 
>>>> 
>>>> 
>>>> From: 
>>>> <swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>>
>>>>  on behalf of Rod Brown via swift-evolution 
>>>> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
>>>> Reply-To: Rod Brown 
>>>> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
>>>> Date: Sunday, May 1, 2016 at 1:25 AM
>>>> To: David Sweeris <daveswee...@mac.com<mailto:daveswee...@mac.com>>
>>>> Cc: Erica Sadun via swift-evolution 
>>>> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
>>>> Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
>>>> 
>>>> 
>>>> On 1 May 2016, at 3:00 PM, David Sweeris 
>>>> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
>>>> 
>>>> On Apr 30, 2016, at 5:42 PM, Rod Brown 
>>>> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>> wrote:
>>>> 
>>>> Re-sent f

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Tod Cunningham via swift-evolution]

+1 on the shadow variable idea.  What an awesome idea.

- Tod





On 5/2/16, 4:41 PM, "Rod Brown" <rodney.bro...@icloud.com> wrote:

>Wow, I'm really sad I missed this while I was writing my last response!
>
>I completely agree with this, and that is a much better solution than the ones 
>previously suggested.
>
>- Rod
>
>
>> On 3 May 2016, at 6:16 AM, David Waite <da...@alkaline-solutions.com> wrote:
>> 
>> It is a bad idea to have the compiler change the interpretation of a type 
>> without some hard and fast rules; the compiler’s interpretation of the 
>> optionality of your code will result in your code being legal or not.
>> 
>> In terms of solutions, I would prefer something similar to a guard statement 
>> that, rather than exiting, shadows a constant or variable with a 
>> non-optional equivalent type, e.g.
>> 
>> shadow var today = today ?? NSDate()
>> let timeInterval = today.timeIntervalSinceNow
>> 
>> -DW
>> 
>>> On May 2, 2016, at 1:27 PM, Tod Cunningham via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> "I wonder if we’re pushing down the road of convenience at the expense of 
>>> truth. The if/guard let syntax is clear that you’re getting a separate 
>>> reference or copy, but what you’re suggesting is hiding the reality from 
>>> the user for what I see as relatively little convenience."
>>> 
>>> It just might be me trying to avoid using !, and especially avoid implicit 
>>> unwrapped options.  While there is nothing wrong with the following code it 
>>> makes me very uncomfortable from a defensive programming point of view:
>>> 
>>>   today = today ?? NSDate()
>>>   let timeInterval = today!.timeIntervalSinceNow
>>> 
>>> Some developer coming along and changing the code could easily introduce a 
>>> crash, such as by removing the default value.  In the above example, such a 
>>> change wouldn’t introduce a compiler warning/error and the bug might not 
>>> reveal itself until a much later.
>>> 
>>> Also using if-let or guard also doesn’t seem right, in this case, as it 
>>> should never fail:
>>> 
>>>  today = today ?? NSDate()   // self.today changed!
>>>  if let today = today {
>>> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>>  } else {
>>> assertFailure()
>>>  }
>>> 
>>> Same issue with guard:
>>> 
>>>  today = today ?? NSDate()   // self.today changed!
>>>  guard let today = today else {
>>> assertFailure()
>>> return //  that should never happen
>>>  }
>>>  let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>> 
>>> This introduces code that just gets in the way of the code’s meaning for 
>>> cases that should never happen.  Yuck, there has to be a better way!
>>> 
>>> - Tod
>>> 
>>> 
>>> 
>>> From: 
>>> <swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>>
>>>  on behalf of Rod Brown via swift-evolution 
>>> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
>>> Reply-To: Rod Brown 
>>> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
>>> Date: Sunday, May 1, 2016 at 1:25 AM
>>> To: David Sweeris <daveswee...@mac.com<mailto:daveswee...@mac.com>>
>>> Cc: Erica Sadun via swift-evolution 
>>> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
>>> Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
>>> 
>>> 
>>> On 1 May 2016, at 3:00 PM, David Sweeris 
>>> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
>>> 
>>> On Apr 30, 2016, at 5:42 PM, Rod Brown 
>>> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>> wrote:
>>> 
>>> Re-sent for Swift Evolution. Response at end.
>>> 
>>> On 1 May 2016, at 6:31 AM, David Sweeris 
>>> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
>>> I think your idea makes a lot more sense in respect to ensuring we don't 
>>> have as much magic.
>>> 
>>> That said, I still wonder about the implications for thread safety etc. 
>>> While it isn't a focus of Swift 3, it's something to think about whether 
>>> this promotes a paradigm that cannot be supported in a threaded 
>>> envir

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown via swift-evolution]

Wow, I'm really sad I missed this while I was writing my last response!

I completely agree with this, and that is a much better solution than the ones 
previously suggested.

- Rod


> On 3 May 2016, at 6:16 AM, David Waite <da...@alkaline-solutions.com> wrote:
> 
> It is a bad idea to have the compiler change the interpretation of a type 
> without some hard and fast rules; the compiler’s interpretation of the 
> optionality of your code will result in your code being legal or not.
> 
> In terms of solutions, I would prefer something similar to a guard statement 
> that, rather than exiting, shadows a constant or variable with a non-optional 
> equivalent type, e.g.
> 
> shadow var today = today ?? NSDate()
> let timeInterval = today.timeIntervalSinceNow
> 
> -DW
> 
>> On May 2, 2016, at 1:27 PM, Tod Cunningham via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> "I wonder if we’re pushing down the road of convenience at the expense of 
>> truth. The if/guard let syntax is clear that you’re getting a separate 
>> reference or copy, but what you’re suggesting is hiding the reality from the 
>> user for what I see as relatively little convenience."
>> 
>> It just might be me trying to avoid using !, and especially avoid implicit 
>> unwrapped options.  While there is nothing wrong with the following code it 
>> makes me very uncomfortable from a defensive programming point of view:
>> 
>>   today = today ?? NSDate()
>>   let timeInterval = today!.timeIntervalSinceNow
>> 
>> Some developer coming along and changing the code could easily introduce a 
>> crash, such as by removing the default value.  In the above example, such a 
>> change wouldn’t introduce a compiler warning/error and the bug might not 
>> reveal itself until a much later.
>> 
>> Also using if-let or guard also doesn’t seem right, in this case, as it 
>> should never fail:
>> 
>>  today = today ?? NSDate()   // self.today changed!
>>  if let today = today {
>> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>>  } else {
>> assertFailure()
>>  }
>> 
>> Same issue with guard:
>> 
>>  today = today ?? NSDate()   // self.today changed!
>>  guard let today = today else {
>> assertFailure()
>> return //  that should never happen
>>  }
>>  let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>> 
>> This introduces code that just gets in the way of the code’s meaning for 
>> cases that should never happen.  Yuck, there has to be a better way!
>> 
>> - Tod
>> 
>> 
>> 
>> From: 
>> <swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>>
>>  on behalf of Rod Brown via swift-evolution 
>> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
>> Reply-To: Rod Brown 
>> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
>> Date: Sunday, May 1, 2016 at 1:25 AM
>> To: David Sweeris <daveswee...@mac.com<mailto:daveswee...@mac.com>>
>> Cc: Erica Sadun via swift-evolution 
>> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
>> Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
>> 
>> 
>> On 1 May 2016, at 3:00 PM, David Sweeris 
>> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
>> 
>> On Apr 30, 2016, at 5:42 PM, Rod Brown 
>> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>> wrote:
>> 
>> Re-sent for Swift Evolution. Response at end.
>> 
>> On 1 May 2016, at 6:31 AM, David Sweeris 
>> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
>> I think your idea makes a lot more sense in respect to ensuring we don't 
>> have as much magic.
>> 
>> That said, I still wonder about the implications for thread safety etc. 
>> While it isn't a focus of Swift 3, it's something to think about whether 
>> this promotes a paradigm that cannot be supported in a threaded environment, 
>> specifically accessing properties.
>> 
>> The if-let paradigm is a lot stronger for this set of actions. It gains a 
>> separate reference or copy to the internal value, and allows you to action 
>> it safely. Should the property change in the meantime, it isn't relevant, 
>> because you have you own reference/copy, and then you have the right to 
>> re-set the property as required.
>> 
>> This, however, would theoretically add in an invisible ! for you. This 
>> leaves you unab

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown via swift-evolution]

Yeah, I definitely see your concerns about such code.

That said, unless the compiler does a lot of rearranging under the covers, all 
you're asking he compiler to do is to hide the ! for you, which is something 
you should be aware of. If the compiler does the rearrangement, you're asking 
for two references or copies to be held while you do what you do. Additionally, 
the compiler could actually start doing so when your don't want it to. It could 
end up with another class of bugs where:

1. You assign to the variable
2. Another thread updates it
3. Later in the same method as the first assignment, you rely on that value 
being correct, but it's only a reference to the initial assignment, not truth.

Writing code that incorrectly states the truth about the value within a 
property to add safety will itself remove other types of safety.

There are easy ways to handle the unsafe case you proposed that don't rely on 
this update, which is to assign to a local variable, update the property, and 
act on the local variable.

let today: NSDate = self.today ?? NSDate()
let timeInterval = today.timeIntervalSinceNow
self.today = today

I think making the compiler rewrite your code in a way that changes the 
semantics of what you wrote to avoid this defensive programming technique ends 
up causing more problems than it solves. It would also make your code factually 
incorrect: you wouldn't be dealing with self.today, as your code would suggest, 
but a local reference (or copy in Swift 3).


> On 3 May 2016, at 5:27 AM, Tod Cunningham <tcunning...@vectorform.com> wrote:
> 
> "I wonder if we’re pushing down the road of convenience at the expense of 
> truth. The if/guard let syntax is clear that you’re getting a separate 
> reference or copy, but what you’r suggesting is hiding the reality from the 
> user for what I see as relatively little convenience."
> 
> It just might be me trying to avoid using !, and especially avoid implicit 
> unwrapped options.  While there is nothing wrong with the following code it 
> makes me very uncomfortable from a defensive programming point of view:
> 
>today = today ?? NSDate()
>let timeInterval = today!.timeIntervalSinceNow
> 
> Some developer coming along and changing the code could easily introduce a 
> crash, such as by removing the default value.  In the above example, such a 
> change wouldn’t introduce a compiler warning/error and the bug might not 
> reveal itself until a much later.
> 
> Also using if-let or guard also doesn’t seem right, in this case, as it 
> should never fail:
> 
>   today = today ?? NSDate()   // self.today changed!
>   if let today = today {
>  let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>   } else {
>  assertFailure()
>   }
> 
> Same issue with guard:
> 
>   today = today ?? NSDate()   // self.today changed!
>   guard let today = today else {
>  assertFailure()
>  return //  that should never happen
>   }
>   let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
> 
> This introduces code that just gets in the way of the code’s meaning for 
> cases that should never happen.  Yuck, there has to be a better way!
> 
> - Tod
> 
> 
> 
> From: 
> <swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
> on behalf of Rod Brown via swift-evolution 
> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
> Reply-To: Rod Brown 
> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
> Date: Sunday, May 1, 2016 at 1:25 AM
> To: David Sweeris <daveswee...@mac.com<mailto:daveswee...@mac.com>>
> Cc: Erica Sadun via swift-evolution 
> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
> Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
> 
> 
> On 1 May 2016, at 3:00 PM, David Sweeris 
> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
> 
> On Apr 30, 2016, at 5:42 PM, Rod Brown 
> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>> wrote:
> 
> Re-sent for Swift Evolution. Response at end.
> 
> On 1 May 2016, at 6:31 AM, David Sweeris 
> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
> I think your idea makes a lot more sense in respect to ensuring we don't have 
> as much magic.
> 
> That said, I still wonder about the implications for thread safety etc. While 
> it isn't a focus of Swift 3, it's something to think about whether this 
> promotes a paradigm that cannot be supported in a threaded environment, 
> specifically accessing properties.
> 
> The if-let paradigm is a lot stronger for this set of actions. It gains a 
> separate reference or copy to the internal value, and all

Re: [swift-evolution] Auto Unwrapping Of Optionals

[David Waite via swift-evolution]

It is a bad idea to have the compiler change the interpretation of a type 
without some hard and fast rules; the compiler’s interpretation of the 
optionality of your code will result in your code being legal or not.

In terms of solutions, I would prefer something similar to a guard statement 
that, rather than exiting, shadows a constant or variable with a non-optional 
equivalent type, e.g.

shadow var today = today ?? NSDate()
let timeInterval = today.timeIntervalSinceNow

-DW

On May 2, 2016, at 1:27 PM, Tod Cunningham via swift-evolution 
<swift-evolution@swift.org> wrote:
> 
> "I wonder if we’re pushing down the road of convenience at the expense of 
> truth. The if/guard let syntax is clear that you’re getting a separate 
> reference or copy, but what you’re suggesting is hiding the reality from the 
> user for what I see as relatively little convenience."
> 
> It just might be me trying to avoid using !, and especially avoid implicit 
> unwrapped options.  While there is nothing wrong with the following code it 
> makes me very uncomfortable from a defensive programming point of view:
> 
>today = today ?? NSDate()
>let timeInterval = today!.timeIntervalSinceNow
> 
> Some developer coming along and changing the code could easily introduce a 
> crash, such as by removing the default value.  In the above example, such a 
> change wouldn’t introduce a compiler warning/error and the bug might not 
> reveal itself until a much later.
> 
> Also using if-let or guard also doesn’t seem right, in this case, as it 
> should never fail:
> 
>   today = today ?? NSDate()   // self.today changed!
>   if let today = today {
>  let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
>   } else {
>  assertFailure()
>   }
> 
> Same issue with guard:
> 
>   today = today ?? NSDate()   // self.today changed!
>   guard let today = today else {
>  assertFailure()
>  return //  that should never happen
>   }
>   let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
> 
> This introduces code that just gets in the way of the code’s meaning for 
> cases that should never happen.  Yuck, there has to be a better way!
> 
> - Tod
> 
> 
> 
> From: 
> <swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
> on behalf of Rod Brown via swift-evolution 
> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
> Reply-To: Rod Brown 
> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
> Date: Sunday, May 1, 2016 at 1:25 AM
> To: David Sweeris <daveswee...@mac.com<mailto:daveswee...@mac.com>>
> Cc: Erica Sadun via swift-evolution 
> <swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
> Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals
> 
> 
> On 1 May 2016, at 3:00 PM, David Sweeris 
> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
> 
> On Apr 30, 2016, at 5:42 PM, Rod Brown 
> <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>> wrote:
> 
> Re-sent for Swift Evolution. Response at end.
> 
> On 1 May 2016, at 6:31 AM, David Sweeris 
> <daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
> I think your idea makes a lot more sense in respect to ensuring we don't have 
> as much magic.
> 
> That said, I still wonder about the implications for thread safety etc. While 
> it isn't a focus of Swift 3, it's something to think about whether this 
> promotes a paradigm that cannot be supported in a threaded environment, 
> specifically accessing properties.
> 
> The if-let paradigm is a lot stronger for this set of actions. It gains a 
> separate reference or copy to the internal value, and allows you to action it 
> safely. Should the property change in the meantime, it isn't relevant, 
> because you have you own reference/copy, and then you have the right to 
> re-set the property as required.
> 
> This, however, would theoretically add in an invisible ! for you. This leaves 
> you unable to handle the situation should the variable have been changed by 
> another thread between your check and your subsequent action.
> 
> Unless I'm missing something, I worry about the behaviour of such a "feature" 
> in a multithreaded environment. I think the previous "inout" idea actually 
> held a lot more weight in this regard - at least then you can act on the 
> copy, and have the change propagate to the main declaration, and overwrite 
> any changes made on another thread.
> 
> I think it would have the same resiliency as if-let, since I was envisioning 
> this to just be syntactic sugar for a switch statement. That is, 

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Tod Cunningham via swift-evolution]

"I wonder if we’re pushing down the road of convenience at the expense of 
truth. The if/guard let syntax is clear that you’re getting a separate 
reference or copy, but what you’re suggesting is hiding the reality from the 
user for what I see as relatively little convenience."

It just might be me trying to avoid using !, and especially avoid implicit 
unwrapped options.  While there is nothing wrong with the following code it 
makes me very uncomfortable from a defensive programming point of view:

today = today ?? NSDate()
let timeInterval = today!.timeIntervalSinceNow

Some developer coming along and changing the code could easily introduce a 
crash, such as by removing the default value.  In the above example, such a 
change wouldn’t introduce a compiler warning/error and the bug might not reveal 
itself until a much later.

Also using if-let or guard also doesn’t seem right, in this case, as it should 
never fail:

   today = today ?? NSDate()   // self.today changed!
   if let today = today {
  let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow
   } else {
  assertFailure()
   }

Same issue with guard:

   today = today ?? NSDate()   // self.today changed!
   guard let today = today else {
  assertFailure()
  return //  that should never happen
   }
   let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow

This introduces code that just gets in the way of the code’s meaning for cases 
that should never happen.  Yuck, there has to be a better way!

- Tod



From: 
<swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
on behalf of Rod Brown via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Reply-To: Rod Brown <rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>>
Date: Sunday, May 1, 2016 at 1:25 AM
To: David Sweeris <daveswee...@mac.com<mailto:daveswee...@mac.com>>
Cc: Erica Sadun via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Subject: Re: [swift-evolution] Auto Unwrapping Of Optionals


On 1 May 2016, at 3:00 PM, David Sweeris 
<daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:

On Apr 30, 2016, at 5:42 PM, Rod Brown 
<rodney.bro...@icloud.com<mailto:rodney.bro...@icloud.com>> wrote:

Re-sent for Swift Evolution. Response at end.

On 1 May 2016, at 6:31 AM, David Sweeris 
<daveswee...@mac.com<mailto:daveswee...@mac.com>> wrote:
I think your idea makes a lot more sense in respect to ensuring we don't have 
as much magic.

That said, I still wonder about the implications for thread safety etc. While 
it isn't a focus of Swift 3, it's something to think about whether this 
promotes a paradigm that cannot be supported in a threaded environment, 
specifically accessing properties.

The if-let paradigm is a lot stronger for this set of actions. It gains a 
separate reference or copy to the internal value, and allows you to action it 
safely. Should the property change in the meantime, it isn't relevant, because 
you have you own reference/copy, and then you have the right to re-set the 
property as required.

This, however, would theoretically add in an invisible ! for you. This leaves 
you unable to handle the situation should the variable have been changed by 
another thread between your check and your subsequent action.

Unless I'm missing something, I worry about the behaviour of such a "feature" 
in a multithreaded environment. I think the previous "inout" idea actually held 
a lot more weight in this regard - at least then you can act on the copy, and 
have the change propagate to the main declaration, and overwrite any changes 
made on another thread.

I think it would have the same resiliency as if-let, since I was envisioning 
this to just be syntactic sugar for a switch statement. That is, this:
if foo is .Result { //`foo` refers to foo's associated or raw value within the 
following code block
//code block
}
would get rewritten to this, for enums with associated values:
switchfoo {
case .Result(let foo): //we get a local copy of `foo` (the associated value) 
for the following code block
//code block
default: break
}
or this, for enums with raw values:
switchfoo {
case .Result:
let _foo = foo.rawValue //the compiler substitutes `_foo` for `foo`
//code block
default: break
}

There’d have to be some more auto-generated code to copy assigned values back 
into the original `foo`, but I don’t think it’d be hard to do.

- Dave Sweeris


Ah yes, that makes sense. So how do you see the compiler dealing with the 
assignment/access problem on structs? If you assign to foo, the compiler 
assigns to both “_foo” and “foo”?

I wonder if we’re pushing down the road of convenience at the expense of truth. 
The if/guard let syntax is clear that you’re getting a separate reference or 
copy, but what you’re su

Re: [swift-evolution] Auto Unwrapping Of Optionals

[David Sweeris via swift-evolution]

> On Apr 29, 2016, at 1:23 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 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?

This can be handled with the if-let syntax:
if let foo = foo as? SomeType { … }
although I think your idea is more readable.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[David Sweeris via swift-evolution]

> On Apr 30, 2016, at 5:42 PM, Rod Brown  wrote:
> 
> Re-sent for Swift Evolution. Response at end.
> 
> On 1 May 2016, at 6:31 AM, David Sweeris  > wrote:
>>> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution 
>>> > wrote:
>>> 
>>> I think this specific proposal asking for compiler magic to auto-unwrap 
>>> invisibly and only in very limited cases, as this proposal suggests, ends 
>>> up breaking a lot more than it fixes. I can only see circumstances of this 
>>> working with variables in the current scope, as anything like a property 
>>> could be updated by other methods, threads etc, and the compiler couldn't 
>>> be certain of state.
>>> 
>>> I think a language feature like you describe would be a lot more helpful, 
>>> but I'd love to hear others' views on that.
>>> 
>>> - Rod
>> 
>> 
>> Yeah, auto-unwrapping "wherever it might be possible" seems too magical to 
>> me. I wouldn’t object to the compiler auto-unwraping optionals within a well 
>> defined code block, though:
>> //foo is T?
>> if foo != nil {
>> //foo is T within this set of curly braces
>> }
>> But even that invokes a bit of compiler magic, in that for this one type of 
>> enum (`Optional`), the compiler knows that if it isn’t one case, it must be 
>> the other. I’d prefer a more general solution…
>> 
>> What if the “is” keyword could function as a kind of incomplete switch?
>> var foo: UnicodeDecodingResult
>> ...
>> if foo is .Result {
>> //since we know foo is a result, `foo` refers to foo's associated or raw 
>> value within this set of curly braces
>> }
>> This allows the language feature (and relevant compiler code paths) to be 
>> used with any enum, not just Optionals. The “optional unwrapping behavior" 
>> could then be written like this:
>> var bar = 4 as Int?
>> ...
>> if bar is .Some {
>> //bar is 4 within this set of curly braces
>> }
>> 
>> - Dave Sweeris
> 
> I think your idea makes a lot more sense in respect to ensuring we don't have 
> as much magic.
> 
> That said, I still wonder about the implications for thread safety etc. While 
> it isn't a focus of Swift 3, it's something to think about whether this 
> promotes a paradigm that cannot be supported in a threaded environment, 
> specifically accessing properties.
> 
> The if-let paradigm is a lot stronger for this set of actions. It gains a 
> separate reference or copy to the internal value, and allows you to action it 
> safely. Should the property change in the meantime, it isn't relevant, 
> because you have you own reference/copy, and then you have the right to 
> re-set the property as required.
> 
> This, however, would theoretically add in an invisible ! for you. This leaves 
> you unable to handle the situation should the variable have been changed by 
> another thread between your check and your subsequent action.
> 
> Unless I'm missing something, I worry about the behaviour of such a "feature" 
> in a multithreaded environment. I think the previous "inout" idea actually 
> held a lot more weight in this regard - at least then you can act on the 
> copy, and have the change propagate to the main declaration, and overwrite 
> any changes made on another thread.


I think it would have the same resiliency as if-let, since I was envisioning 
this to just be syntactic sugar for a switch statement. That is, this:
if foo is .Result { //`foo` refers to foo's associated or raw value within the 
following code block
//code block
}
would get rewritten to this, for enums with associated values:
switch foo {
case .Result(let foo): //we get a local copy of `foo` (the associated value) 
for the following code block
//code block
default: break
}
or this, for enums with raw values:
switch foo {
case .Result:
let _foo = foo.rawValue //the compiler substitutes `_foo` for `foo`
//code block
default: break
}

There’d have to be some more auto-generated code to copy assigned values back 
into the original `foo`, but I don’t think it’d be hard to do.

- Dave Sweeris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown via swift-evolution]

Re-sent for Swift Evolution. Response at end.

On 1 May 2016, at 6:31 AM, David Sweeris  wrote:
>> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution 
>>  wrote:
>> 
>> I think this specific proposal asking for compiler magic to auto-unwrap 
>> invisibly and only in very limited cases, as this proposal suggests, ends up 
>> breaking a lot more than it fixes. I can only see circumstances of this 
>> working with variables in the current scope, as anything like a property 
>> could be updated by other methods, threads etc, and the compiler couldn't be 
>> certain of state.
>> 
>> I think a language feature like you describe would be a lot more helpful, 
>> but I'd love to hear others' views on that.
>> 
>> - Rod
> 
> 
> Yeah, auto-unwrapping "wherever it might be possible" seems too magical to 
> me. I wouldn’t object to the compiler auto-unwraping optionals within a well 
> defined code block, though:
> //foo is T?
> if foo != nil {
> //foo is T within this set of curly braces
> }
> But even that invokes a bit of compiler magic, in that for this one type of 
> enum (`Optional`), the compiler knows that if it isn’t one case, it must be 
> the other. I’d prefer a more general solution…
> 
> What if the “is” keyword could function as a kind of incomplete switch?
> var foo: UnicodeDecodingResult
> ...
> if foo is .Result {
> //since we know foo is a result, `foo` refers to foo's associated or raw 
> value within this set of curly braces
> }
> This allows the language feature (and relevant compiler code paths) to be 
> used with any enum, not just Optionals. The “optional unwrapping behavior" 
> could then be written like this:
> var bar = 4 as Int?
> ...
> if bar is .Some {
> //bar is 4 within this set of curly braces
> }
> 
> - Dave Sweeris

I think your idea makes a lot more sense in respect to ensuring we don't have 
as much magic.

That said, I still wonder about the implications for thread safety etc. While 
it isn't a focus of Swift 3, it's something to think about whether this 
promotes a paradigm that cannot be supported in a threaded environment, 
specifically accessing properties.

The if-let paradigm is a lot stronger for this set of actions. It gains a 
separate reference or copy to the internal value, and allows you to action it 
safely. Should the property change in the meantime, it isn't relevant, because 
you have you own reference/copy, and then you have the right to re-set the 
property as required.

This, however, would theoretically add in an invisible ! for you. This leaves 
you unable to handle the situation should the variable have been changed by 
another thread between your check and your subsequent action.

Unless I'm missing something, I worry about the behaviour of such a "feature" 
in a multithreaded environment. I think the previous "inout" idea actually held 
a lot more weight in this regard - at least then you can act on the copy, and 
have the change propagate to the main declaration, and overwrite any changes 
made on another thread.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Alan Skipp via swift-evolution]

> On 29 Apr 2016, at 15:37, Tod Cunningham via swift-evolution 
>  wrote:
> 
> 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 ...
>}
> }

I can’t say I’m keen on adding further compiler magic to Optionals, each 
special case adds further complication to the concept.

An alternative take on the example code posted would be: should the property be 
an Optional? If there is an Optional property which can later be replaced with 
a default value (today = today ?? NSDate()), perhaps the property should have 
been assigned the default non-optional value to begin with? Avoiding having to 
deal with the ceremony of Optionals all together.

I appreciate that the example code you posted was a succinct way to demonstrate 
the use case you had in mind and not meant as a `real world` case, but it does 
highlight that if a property has a valid default value, it probably shouldn’t 
be an Optional. The great thing about Optionals is that there’s the choice to 
avoid them as much as possible : )

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[James Campbell via swift-evolution]

That would be handy

Sent from Supmenow.com




On Sat, Apr 30, 2016 at 1:31 PM -0700, "David Sweeris via swift-evolution" 
 wrote:











On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution 
 wrote:
I think this specific proposal asking for compiler magic to auto-unwrap 
invisibly and only in very limited cases, as this proposal suggests, ends up 
breaking a lot more than it fixes. I can only see circumstances of this working 
with variables in the current scope, as anything like a property could be 
updated by other methods, threads etc, and the compiler couldn't be certain of 
state.
I think a language feature like you describe would be a lot more helpful, but 
I'd love to hear others' views on that.
- Rod
Yeah, auto-unwrapping "wherever it might be possible" seems too magical to me. 
I wouldn’t object to the compiler auto-unwraping optionals within a well 
defined code block, though://foo is T?if foo != nil {//foo is T within this set 
of curly braces}But even that invokes a bit of compiler magic, in that for this 
one type of enum (`Optional`), the compiler knows that if it isn’t one case, it 
must be the other. I’d prefer a more general solution…
What if the “is” keyword could function as a kind of incomplete switch?var foo: 
UnicodeDecodingResult...if foo is .Result {    //since we know foo is a result, 
`foo` refers to foo's associated or raw value within this set of curly 
braces}This allows the language feature (and relevant compiler code paths) to 
be used with any enum, not just Optionals. The “optional unwrapping behavior" 
could then be written like this:var bar = 4 as Int?...if bar is .Some {    
//bar is 4 within this set of curly braces}
- Dave Sweeris





___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[David Sweeris via swift-evolution]

> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution 
>  wrote:
> 
> I think this specific proposal asking for compiler magic to auto-unwrap 
> invisibly and only in very limited cases, as this proposal suggests, ends up 
> breaking a lot more than it fixes. I can only see circumstances of this 
> working with variables in the current scope, as anything like a property 
> could be updated by other methods, threads etc, and the compiler couldn't be 
> certain of state.
> 
> I think a language feature like you describe would be a lot more helpful, but 
> I'd love to hear others' views on that.
> 
> - Rod


Yeah, auto-unwrapping "wherever it might be possible" seems too magical to me. 
I wouldn’t object to the compiler auto-unwraping optionals within a well 
defined code block, though:
//foo is T?
if foo != nil {
//foo is T within this set of curly braces
}
But even that invokes a bit of compiler magic, in that for this one type of 
enum (`Optional`), the compiler knows that if it isn’t one case, it must be the 
other. I’d prefer a more general solution…

What if the “is” keyword could function as a kind of incomplete switch?
var foo: UnicodeDecodingResult
...
if foo is .Result {
//since we know foo is a result, `foo` refers to foo's associated or raw 
value within this set of curly braces
}
This allows the language feature (and relevant compiler code paths) to be used 
with any enum, not just Optionals. The “optional unwrapping behavior" could 
then be written like this:
var bar = 4 as Int?
...
if bar is .Some {
//bar is 4 within this set of curly braces
}

- Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown via swift-evolution]

I definitely agree there are difficulties with working with nullability and 
structs. Interesting perspective on how to deal with that. I'd be interested in 
what others think of your inout type idea.

I think this specific proposal asking for compiler magic to auto-unwrap 
invisibly and only in very limited cases, as this proposal suggests, ends up 
breaking a lot more than it fixes. I can only see circumstances of this working 
with variables in the current scope, as anything like a property could be 
updated by other methods, threads etc, and the compiler couldn't be certain of 
state.

I think a language feature like you describe would be a lot more helpful, but 
I'd love to hear others' views on that.

- Rod

> On 30 Apr 2016, at 5:22 PM, Haravikk  wrote:
> 
> 
>> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution 
>>  wrote:
>> 
>> 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.
> 
> Actually, thinking about it a bit more I think that the main case where I 
> would want something like this is actually, something more like the following:
> 
>   if var unwrappedFoo = self.foo {
>   unwrappedFoo.mutate()   // self.foo is unchanged, we have to do 
> this:
>   self.foo!.mutate()  // original is changed, but 
> unwrappedFoo is not
>   // foo was changed once, not twice
>   }
> 
> Of course classes follow different rules, but it’s a little counter-intuitive 
> for structs, what if we could do something like this:
> 
>   if inout unwrappedFoo = self.foo {
>   unwrappedFoo.mutate()   // both are changed
>   self.foo!.mutate()  // no longer required this
>   // foo was changed twice, and both forms are consistent
>   }
> 
> i.e- inout in this case gets us a non-optional reference to the original 
> value, not a copy (or potential copy). In the event that self.foo is changed 
> somewhere else, unwrappedFoo would continue to reference to what it used to 
> be and remain usable, though of course in the above example the call to 
> self.foo! would fail in such a case, but it should no longer be required.
> 
> 
> At least in my experience this is the most common case that I encounter, as I 
> try to use if let or guard let (or var) for safety, but then this doesn’t 
> help when manipulating a struct, so a third option could be useful in such 
> cases.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[James Campbell via swift-evolution]

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 \(t

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Haravikk via swift-evolution]

> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution 
>  wrote:
> 
> 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.

Actually, thinking about it a bit more I think that the main case where I would 
want something like this is actually, something more like the following:

if var unwrappedFoo = self.foo {
unwrappedFoo.mutate()   // self.foo is unchanged, we have to do 
this:
self.foo!.mutate()  // original is changed, but 
unwrappedFoo is not
// foo was changed once, not twice
}

Of course classes follow different rules, but it’s a little counter-intuitive 
for structs, what if we could do something like this:

if inout unwrappedFoo = self.foo {
unwrappedFoo.mutate()   // both are changed
self.foo!.mutate()  // no longer required this
// foo was changed twice, and both forms are consistent
}

i.e- inout in this case gets us a non-optional reference to the original value, 
not a copy (or potential copy). In the event that self.foo is changed somewhere 
else, unwrappedFoo would continue to reference to what it used to be and remain 
usable, though of course in the above example the call to self.foo! would fail 
in such a case, but it should no longer be required.


At least in my experience this is the most common case that I encounter, as I 
try to use if let or guard let (or var) for safety, but then this doesn’t help 
when manipulating a struct, so a third option could be useful in such cases.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown via swift-evolution]

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Michael Peternell via swift-evolution]

I thought about this too, and I think it would be convenient. It feels a bit 
like artificial intelligence though, and I'm not sure how easy it would be to 
implement this. It should be sharply defined what the compiler should infer and 
what not. This can be very hard.

For example, you write `print("Today is \(today)")`: should it print an 
Optional or should it print just the date, because it knows that it cannot be 
nil? I say it should print `.Optional(... 23:37)`. But what if it prints just 
the date? In this case `today` cannot be nil, so it would be safe to just print 
`23:37`. Now, I see the source code example for the first time. What thinking 
process do I have to go through to know if the variable is automatically 
unwrapped or not? I'll think "can this variable be nil at that place?" The 
compiler also thinks "can this variable be nil at that place?" Will the 
compiler and me always agree in this respect? Or do I have to think "Will the 
compiler think that the variable can be nil at this place? Can it decide that 
it can never be nil?"? In this case, the language user needs to have a mental 
model about what inferences the compiler is able to do, so the rules must be 
fixed and easily understandable. The model would probably be something along 
the lines of "NSDate() always returns a non-optional value, so `x ?? NSDate()` 
is non-optional too." But knowing that foo(3) will return a value because foo 
only returns nil if its argument is < 0 is probably out of scope, even if the 
foo-function is defined within the same source file and even if the `-O2` flag 
is turned on (because you don't want to have different semantics depending on 
how much optimization is turned on).

Therefore, I think it would be best to only apply implicit unwrapping in cases 
where the code would otherwise not compile.

E.g. now you have to write

var x: Int? = someFunction()
if(x == nil) { return 22 }
return x!+2+(2*x!);

It should be possible to rewrite this as

var x: Int? = someFunction()
if(x == nil) { return 22 }
return x+2+(2*x);

This should only work for variables defined within the same scope, so this 
should fail to compile:

// type of self.foo is String
if(self.foo == nil) { return 11 }
// type of myFunc is String -> ()
myFunc(self.foo)
  
because even though self.foo was non-nil 1 microsecond ago, it doesn't mean 
that it is non-nil now.

On the other hand, what happens if a variable is captured by a block? Do we 
know that the variable is not mutated from another thread? Should we disable 
all these rules as soon as there is a block somewhere that captures one of the 
variables and might mutate them?

I just started thinking... For all these reasons, I don't see how this is going 
to be implemented in a way that is consistent and that doesn't introduce all 
kinds of strange edge cases. And any solution should be comprehensible by a 
Swift-beginner IMHO. On the other hand, if I ever forget a "!" somewhere, and 
the compiler compiles it anyways because it knows that it is safe, I will not 
complain :)

-Michael

> Am 29.04.2016 um 16:37 schrieb Tod Cunningham via swift-evolution 
> :
> 
> 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 

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Tod Cunningham via swift-evolution]

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: 
<swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
on behalf of Adrian Zubarev via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Reply-To: Adrian Zubarev 
<adrian.zuba...@devandartist.com<mailto:adrian.zuba...@devandartist.com>>
Date: Friday, April 29, 2016 at 3:21 PM
To: "swift-evolution@swift.org<mailto:swift-evolution@swift.org>" 
<swift-evolution@swift.org<mailto: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<mailto: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 // Expl

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Adrian Zubarev via swift-evolution]

+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(mailto: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

Re: [swift-evolution] Auto Unwrapping Of Optionals

[Haravikk via swift-evolution]

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

[swift-evolution] Auto Unwrapping Of Optionals

[Tod Cunningham via swift-evolution]

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