> On 1 May 2016, at 3:00 PM, David Sweeris <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: > 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
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
