I don't think we're likely to do anything about this. The compiler can't see how flatMap is going to use its argument, and so it has to assume it might throw. (For this general reason, rethrows functions always decay into throws functions when you use them as a value.)

Doesn't the throws–rethrows pairing give the compiler enough to know that if the function passed isn't marked throws then the try isn't needed? (I guess this wouldn't be the case for functions with multiple higher-order arguments.) If I define non-throws overloads for map and flatMap it surprisingly seems to work (I was worried about creating ambiguity).

I haven't thought it through whether rethrows on the called function means that rethrows on a function argument can be dropped.

cc @rudkx

{map} is declared {rethrows}. We do not know what {map} is going to be applied to so we have to assume it can throw, and thus the overall expression can throw.

Please feel free to reopen if you think there is something else going on here that I'm missing.