cc @xedin @hamishknight

The problem here seems like for the case:

// Cannot convert value of type 'Result<String, Error>' to expected argument type 'DispatchTimeoutResult'
if r == .success {
    print("yay?")
}

The solver is inferring .success as DispatchTimeoutResult.result, I didn't debug it, but apparently that's the best solution it is finding of all disjunction choices.
So maybe adjusting this to favor the binding Result<String, Error> in some way (since the type of r is known upfront) could improve the situation? @xedin

For the other case

// Binary operator '==' cannot be applied to two 'Result<String, Error>' operands
if r == .success(_) {
    print("yay?")
}

Just tweak the diagnostics when involving an enum with value?

Diagnostic for `r == .success` is definitely incorrect it should at least be `cannot be applied to operands`, but the main issue here is that `==` can't be used to pattern match `r` to `.success(_)`, that's the job of `if case`.

@swift-ci create

@xedin Yeah, there is something interesting happening here... if we remove the Foundation import, we got a `cannot be applied to operands` for `r == .success` that is why I mentioned that it could be that the solver is finding `DispatchTimeoutResult` defined in Foundation as the solution for the base type of `.success`(DispatchTimeoutResult.success that is a case without associated value) which leads to bad diagnostic.

I still didn't debug it so this is just a guess, but I was curious about why this may be happening.