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 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
