[swift-evolution] try? shouldn't work on non-method-call

Sikhapol Saijit sikhapol at gmail.com
Thu Aug 18 00:43:08 CDT 2016


Hi all,


Yesterday I tried this code:

func couldFailButWillNot() throws -> Any {
    return 42
}

if let a = try? couldFailButWillNot() as? Int {
    print(a)
}

And was surprised that the output was Optional(42) on both Swift 2 and Swift 3.
I always have the impression that when a variable is resolved with if let it will never be optional.

So, with a little investigation, I found out that it happens because as? has higher precedence than try? and is evaluated first.
And the whole expression `try? couldFailButWillNot() as? Int` evaluated as Optional(Optional(42)).

Also, I’m surprised that try? can be used with non-method-call.
This code: `print(try? 42)` will print Optional(42).

So, the questions are:

1. Is it intentional that try? can be used with a "non-method-call" and return an optional of the type that follows?

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 

3. Do you think that doubly-nested optional (or multi-level-nested optional) is confusing and should be removed from Swift? (Yes, I’ve seen this blog post Optionals Case Study: valuesForKeys <https://developer.apple.com/swift/blog/?id=12>).
For me Optional(nil) (aka Optional.Some(Optional.None))) doesn’t make much sense. 
Maybe, one of the solution is to always have optional of optional merged into a single level optional? Like Optional(Optional(Optional(42))) should be the merged to and evaluated as Optional(42).

BTW, the code above is merely for a demonstration. The actual code was more of something like this:

func parse(JSON: Data) throws -> Any {
    // …
}

if let dict = try? parse(JSON: json) as? [String: Any] {
    // assume dict is a valid [String: Any] dictionary
    // …
}

I’m new to this mailing list so I’m not sure if this belongs here. I’m sorry in advance if it doesn’t.


Thank you,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160818/131672de/attachment.html>


More information about the swift-evolution mailing list