Opinions inline:
> On 18 Aug 2016, at 07:43, Sikhapol Saijit via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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?
I think this is the real solution. try and try? should not be allowed on
non-throwing functions or expressions.
> 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
That’s worth considering. try feels like it should tie very strongly with the
throwing expression.
> 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).
I don’t think this is the solution. Even if it was, how would you expect to
“remove” them from Swift? Optionals are simply an enum with an associated
value. We’d have to introduce a language feature to restrict values that can be
stored in enum cases? It sounds awfully complicated.
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
