Sorry for the resend! Some of my previous e-mail was left out for some reason. 
Here it is again, as it should have been:

> On Aug 18, 2016, at 12:43 AM, Sikhapol Saijit via swift-evolution 
> <[email protected] <mailto:[email protected]>> wrote:
> 
> 1. Is it intentional that try? can be used with a "non-method-call" and 
> return an optional of the type that follows?

a. I’m not sure what you mean by “non-method-call”, since the thing you called 
in your example *was* a function that was marked with “throws”. Using try? on a 
non-throwing function or method does indeed produce a warning.

b. I’m not an Apple employee or a member of the development team, but I think 
it probably is intentional. There are two levels of optionality going on here; 
one, the possibility that the throwing method could have failed, and the other, 
that the optional result may or may not contain a value. Either of those two 
things being nil could mean quite different things, so the double-optional 
makes sense.

> 2. Should we design try? to have higher precedence than as? or any operators 
> at all?
> My intuition tells me that 
> let a = try? couldFailButWillNot() as? Int
> should be equivalent to
> let a = (try? couldFailButWillNot()) as? Int 

This is more debatable whether it *should* be the case, but it’s worth pointing 
out that try/try?/try! work on the entire rest of the line, which means you can 
include more throwing calls and not have to put an ! each time:

func foo() throws -> Int { return 3 }

func bar() throws -> Int { return 5 }

if let i = try? foo() + bar() { // not try foo() + try bar()
    print("i is \(i)")
}

Or this:

func foo() throws -> Int { return 3 }

func bar(_ i: Int) throws -> Int { return i + 2 }

if let i = try? bar(foo()) { // not bar(try foo())
    print("i is \(i)")
}

So multiple throwing statements can be used on a single line without having to 
throw “try” all over the place. Now, whether that’s worth the admittedly 
confusing behavior you noted above is probably a decent topic for debate.

Charles
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to