> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution
> <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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
