@xedin, comments?

nschum (JIRA User) I agree that it does look inconsistent but it actually makes sense as soon as you know what the rules are here (it all comes down to number of conversions which need to happen): It takes less conversions to convert Int? to Any vs. Any? because that would require converting Int to Any and converting Optional<Int> to Optional<Any>, regarding nil to Any - it can't be converted, but nil to Any? can be.

Same goes for collections - [42] is type-checked as [Int] because 42 is integral literal with default type of Int ,which means that it takes less conversions to get to Any vs. [Any], where both Int as to be converted to Any and array has to be upcast from [Int] to [Any].

I'm not sure I agree with that ranking, but it is what we have implemented.

Comment by Nikolaj Schumacher (JIRA)

@xedin Those rules don't seem to quite match all the effects I've noticed.

If Any is preferable to Any? due to fewer conversions, why is this call ambiguous:

func foo(_: [Any]) {print(1)}
func foo(_: [Any?]) {print(2)}

let x: Int? = 42
foo([x]) // ambiguous

Also, in the following case Any?? is preferred. According to your description, it should need at least as many conversions as `Any?`.

func foo(_: Any?) {print(1)}
func foo(_: Any??) {print(2)}

let x: Int?? = 42
foo(x) // 2

(Not that `Any??` has many real world applications 😉)

If Any is preferable to Any? due to fewer conversions, why is this call ambiguous:

That example is no longer ambiguous with the master compiler, I think it was a bug I fixed recently related to array subtyping. It's actually going to prefer `[Any?]` in this case.

Also, in the following case Any?? is preferred. According to your description, it should need at least as many conversions as `Any?`.

Since Any?? and Int?? here have the same optionality level there is only one conversion which needs to happen this case -> Int to Any, but in case of Any? - it has to get promoted to one more level of optionality to become Any?? and then Int?? converts to Any??