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 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 suggesting is hiding the reality from the >> user for what I see as relatively little convenience. >> >> This is not to say I don’t see the problem, or the convenience… I just >> wonder if this might be going a little too far. >> >> - Rod >> >> _______________________________________________ >> 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