> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution
> <[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()
^
>
>> 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
>
> _______________________________________________
> 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
