[SR-7318] Type interference sometimes is wrong on equality check

[swift-ci]

Previous ID	SR-7318
Radar	rdar://problem/39143381
Original Reporter	vhbit (JIRA User)
Type	Bug

Environment

Swift 4.1 from Xcode 9.3 (9E145)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, 4.1Regression, TypeChecker
Assignee	None
Priority	Medium

md5: 30fd51ff3ed5acce33a3e35add5f858d

Issue Description:

It seems that sometimes when checking equality with `.none` the other argument is promoted to Optional which causes unexpected results compared to Swift 4.0

enum Foo {
    case none
    case always
    case smart
}

struct Bar {
    let foo: Foo
}

let x: Foo = .none
x != .none // false as expected

let y: Bar? = Bar(foo: x)
(y?.foo ?? .none) != .none // unexpectedly returns true, worked fine on Swift 4.0
(y?.foo ?? .none) != Foo.none // false as expected

[belkadan]

Hm. What changed in 4.1? @xedin?

@swift-ci create

[belkadan]

(May be a standard library change, we'll see.)

[xedin]

Interesting, since `Optional` is now `Equitable` if '.none', on the right-hand side, is spelled without the base `!=` is inferred as (Foo?, Foo?) -> Bool`, if it's spelled as `Foo.none` it's inferred as `(Foo, Foo) -> Bool`, because `.none` could be interpreted as `Optional.none` instead of `Foo.none`.

/cc @moiseev

[xedin]

/cc @DougGregor

[DougGregor]

As @xedin notes, `.none` could be interpreted either way. The `Foo.none` solution is better, in the sense that it doesn't require an optional injection on the left-hand side of the `!=` operator, so Swift 4.0 was correct to choose it.

[xedin]

@DougGregor Bigger issue here is that both `!=` overloads that form solutions are declared in protocol extensions, one on `Equatable` `(Self, Self) -> Bool` and another one on `Optional` `(Wrapped?, Wrapped?) -> Bool` and the latter one is more specialized because it's conditional on associated type, that's why we pick `.none` to be `Optional.none` in that example.