By a quick look to solver debug output the problem in this case is just ambiguity where solver finds 2 viable solutions `(@convention(block) () -> Void)?` and `(() -> ())?` for ternary result type var.

That is a workaround, of course. I wouldn't mind that for tiny closures, but with a signature with with 5+ parameters this becomes a very painful experience.

Ah, for the case with @conversion(c) is really not possible to convert from a closure that is inferred as a swift closure to a c convention one(except in some cases where compiler can determine context statically). So, basically almost all thick(swift, block) to thin(c, thin) conversions are not allowed because thick(swift, block) closures can capture context.
In the first case with block should not be ambiguous, it should typecheck correctly.

@swift-ci create

Thanks for the input @LucianoPAlmeida. The issue is not about being able to convert between different conventions, it's about the compiler failing to accept two valid ones in a rather very simple (from the end usage perspective) scenario. The original issue I've run in was with … ? nil : {} and @convention(c) (like the first approach). My guess is that the compiler doesn't assume (but needs to) that both block operands are of the same convention as the declaration it's being assigned to. The error in second example is the consequence of that – both block don't capture context and are valid to be passed into C.

Fixed on main by #36208
@iby Can you please verify on the next available snapshot and close? Thanks