Adjust for 'try?' changes in Swift 5

[bjhomer]

When 'try?' has an optional sub-expression, it no longer produces a nested optional.

[rudkx]

@swift-ci Please smoke test

[rudkx]

I don't see where swift-corelibs-foundation is actually building with -swift-version 5 yet.

Also, there are a number of other uses of try? in the project - are you sure this is the only one that would need adjusting when building with -swift-version 5?

[bjhomer]

Hm. I believe we've got tests in try.swift to make sure that this behavior has not changed in Swift 4 mode. I'm not familiar with how swift-corelibs-foundation builds, but it does appear like it's using -swift-version 5 based on the behavior here.

I haven't done an exhaustive search yet, but this was the only use of try? that initially stood out. I'll keep looking.

[bjhomer]

There are only two cases of try? ... as? in swift-corelibs-foundation, and the other one (in TestNSNumber.swift) does not need to be changed. So this is the only case matching that particular pattern, which is the most common case of the try? double-optional in the wild.

[bjhomer]

I just looked at all the uses of try? in Foundation. This is the only one that needs to be changed for swift-version 5. So the question is just whether it should be building with v5 yet.

[bjhomer]

Based on the rejected PR here (https://github.com/apple/swift-corelibs-foundation/pull/1774/files), it looks like the foundation tests are using swift-version 5 by default. (The PR was to set it back to version 4, but that change was not made)

[shahmishal]

@swift-ci test

[shahmishal]

Merged to unblock CI.

[rudkx]

@bjhomer Okay, I had missed that the compiler was actually defaulting to -swift-version 5 as of yesterday, but apparently that's the case.