Somewhat more generally, it isn't that uncommon that Swift produces a diagnostic of the form "cannot do x with ... some types ..." ... expected an argument list of type ... some type args, which the previous statement obviously satisfies...".

Would it be possible for the type checker to simply detect when it is going to emit this kind of poor diagnostic, and emit something more verbose?

I suspect what's going on here is the only way for min() to be valid there is if the type it returns is a SequenceType, which means that the min() call's generic parameter T is being given an implicit bound <T: SequenceType>. Given that bound. min(1, 2) is not valid, because Int does not conform to SequenceType. So the problem here isn't that the error is a poor error in general (it's not; it's perfectly legitimate in the cases where it's actually accurate), but that the diagnostic does not recognize that the failure is caused by an implicit bound that is not actually part of the min() call itself.

So basically, instead of determining that the arguments aren't valid because they don't satisfy the bound, it should determine that the arguments are valid for the expression in isolation, but that the resulting expression type doesn't satisfy the bound, and should therefore report the error as being that the expression's type Int does not conform to SequenceType (or that it has no member Generator as that seems to be what the error today is for for i in 1).

This just got merged in e15d08e. The new error for this code should be: `type 'Int' does not conform to protocol 'SequenceType'`