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@swift.org> wrote:
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
