> On Aug 18, 2016, at 1:42 AM, Slava Pestov via swift-evolution > <[email protected]> wrote: > >> >> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Opinions inline: >> >>> On 18 Aug 2016, at 07:43, Sikhapol Saijit via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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. > > This is a warning right now — do you think it should be an error? > > Slavas-MacBook-Pro:~ slava$ cat ttt.swift > func f() {} > > func g() { > try f() > try? f() > } > > Slavas-MacBook-Pro:~ slava$ swiftc ttt.swift > ttt.swift:4:3: warning: no calls to throwing functions occur within 'try' > expression > try f() > ^ > ttt.swift:5:8: warning: no calls to throwing functions occur within 'try' > expression > try? f() > ^
… Replying to myself: I also think it would be more logical for this to be an error, but I vaguely recall some internal discussion where we agreed that removing ‘throws’ from a function should not break source or binary compatibility (I don’t know if the current implementation makes good on the latter). Jordan, do you remember the reasoning for this being a warning and not an error? > >> >>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
