[swift-evolution] Auto Unwrapping Of Optionals

[James Campbell]

That would be handy

Sent from Supmenow.com




On Sat, Apr 30, 2016 at 1:31 PM -0700, "David Sweeris via swift-evolution" <swift-evolution at swift.org> wrote:











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/a99ea22a/attachment.html>