On Thu, Aug 18, 2016 at 11:30 AM, John McCall <rjmcc...@apple.com> wrote:
> On Aug 18, 2016, at 8:46 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> The issue would be that, in the case of "try? foo()", nil and .some(nil)
> might mean very different things.
>
>
> This is true of a?.foo() as well. But yes, I think it is more likely that
> someone would want to treat them differently for try?.
>
Agreed.
My proposed solution was half-baked, but it may be workable--I'm not
suggesting typing decisions based on a dynamic property, of course. It'd be
something like this:
`as?` would produce a result of a type named something like
CastingOptional<T>, which on assignment or essentially any other operation
is promoted/bridged/[insert much more correct term here] to an Optional<T>
like how T is automatically promoted to Optional<T>. However, `try?` will
not wrap a CastingOptional<T> into an Optional<Optional<T>>.
> John.
>
> On Thu, Aug 18, 2016 at 10:40 John McCall <rjmcc...@apple.com> wrote:
>
>> On Aug 18, 2016, at 8:19 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Lots of interesting points here. I do think there's an improvement
>> possible here, but it's actually along the lines of Sam's original
>> suggestion #3 (not vis-a-vis all of Swift, but specifically for how try?
>> composes with as?):
>>
>> A. I'm in favor of the current behavior where try prefixes an entire
>> statement: it solves the precise issue of multiple nested optionals or
>> multiple unwrapping of optionals in the situation where one statement has
>> calls to many throwing functions. It says instead, I want nil if anything
>> in this statement throws, otherwise, give me .some(value).
>>
>> Sam--I think you may have misunderstood Charles's explanation. He's not
>> saying "try?" attaches with lower or higher precedence as compared to
>> "as?". Rather, I think the mental model is that "try?" prefixes the whole
>> right-hand side (rhs), and if *any* call on the rhs throws, the whole rhs
>> evaluates to nil, but if *any* call could potentially throw but doesn't,
>> "try?" wraps the entire rhs and gives you .some(value). IMO, this is pretty
>> sensible for the reason he gives.
>>
>> B. I'm in favor of warning instead of error, for precisely the internal
>> discussion rationale communicated by Slava. I'm willing to live with "try?
>> 42" being only a warning if that means my code won't stop compiling when
>> someone decides a library function doesn't need to throw.
>>
>> Sam--here, changing warning to error would not solve your original
>> problem, because in that example "try?" does prefix at least one throwing
>> function, so you wouldn't get an error anyway.
>>
>> C. However, given the thinking in (A), I do think how "try?" composes
>> with "as?" is a little counterintuitive or at least overly ceremonious,
>> though technically it is possible to reason through.
>>
>> It's true that currently you can use the multiple nested optionals to
>> figure out whether either a throwing function threw (but not which throwing
>> function out of potentially more than one) or whether the cast did not
>> succeed. But, since "try?" after all means "give me nil if anything
>> throws," it kind of makes less sense that you get all this nesting and
>> detailed information when it composes with "as?". If you really wanted that
>> level of detail, you could always evaluate "try?" and "as?" in separate
>> statements. What I'd propose instead is this:
>>
>> If "try?" is composed with "as?", and "as?" yields "nil", then "try?"
>> should not wrap that value in another optional.
>>
>>
>> We can't make the typing decision dependent on a dynamic property like
>> whether the cast fails. And I don't like the idea of changing its typing
>> rule based on the form of the nested expression. But we could make "try?
>> foo()" avoid adding an extra level of optionality, the same way that
>> "a?.foo()" does.
>>
>> John.
>>
>>
>> Does that sound sensible?
>>
>>
>> On Thu, Aug 18, 2016 at 3:54 AM, Sikhapol Saijit via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>> On Aug 18, 2016, at 3:42 PM, Slava Pestov <spes...@apple.com> wrote:
>>>
>>>
>>> On Aug 18, 2016, at 12:52 AM, David Hart via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> 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.
>>>
>>>
>>> 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()
>>> * ^*
>>>
>>>
>>> Thank you Slava,
>>>
>>> While I think using try/try? on anything but a throwing function call
>>> should be an error, right now it even works with anything. `try? 42` will
>>> just wrap 42 in an optional and give some warning now.
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
