> On Apr 30, 2016, at 5:42 PM, Rod Brown <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:
>>> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
