[swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

let today = today else { >>>>assertFailure() >>>>return // that should never happen >>>> } >>>> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow >>>> >>>> This introduces code that ju

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

;> 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 >&g

Re: [swift-evolution] Auto Unwrapping Of Optionals

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&

Re: [swift-evolution] Auto Unwrapping Of Optionals

te: 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 Opti

Re: [swift-evolution] Auto Unwrapping Of Optionals

y.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>> Subje

Re: [swift-evolution] Auto Unwrapping Of Optionals

> 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

Re: [swift-evolution] Auto Unwrapping Of Optionals

> 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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

> 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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

> 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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

> 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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

ot;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 {

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

Re: [swift-evolution] Auto Unwrapping Of Optionals

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

[swift-evolution] Auto Unwrapping Of Optionals

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