Given the relationship between throwing and non-throwing functions, I'm surprised this doesn't already just work. A non-throwing function has the same calling convention as a throwing one, it simply never touches the error-out parameter.
Unless I'm seriously misremembering how that works.
The issue isn't the relationship between throwing and non-throwing function types (as you note, the proper subtype relationship exists already), but the fact that the second argument of && is an @autoclosure param, so the full type is (Bool, @autoclosure () throws -> Bool) throws -> Bool. The reduce method expects (Bool, Bool) throws -> Bool, so the types are incompatible.
Yeah, that makes sense. I had a brainfart and completely forgot that this code was trying to pass a Bool to a () -> Bool parameter.
This is close to being a motivating example to add & and | overloads that are (Bool, Bool) -> Bool.
Aha! Thanks!
Any reason (except that no one has taken the time) that @autoclosure-argument expecting function couldn’t be used where a normal function is required?
It can automatically wrap an argument expression in a closure When calling directly, but not when partially applying the function.
There's been some recent discussion of this in "Adding autoclosure breaks the function's usage?".
I also raised another related issue with the @autoclosure solution for short-circuiting boolean operations here a while back. I'd definitely support a proposal to add non-short-circuiting versions if it doesn't result in serious type-checker issues!