[swift-evolution] Auto Unwrapping Of Optionals

[David Sweeris]

> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution <swift-evolution at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160430/dba1257d/attachment.html>