Overload resolution chooses type that's invalid, too general or not at all

Timo Kinnunen timo.kinnunen at gmail.com
Fri Jan 10 03:05:42 PST 2014


  Hi,

In the case where the difference between two target types is only that one
of them has a generic throws declaration, this leads to ambiguity even when
choosing the wrong one would be a compile error.

This seems to be working as specified, with the goal to make the result
more stable and predictable, but I would argue the actual result is just
the opposite. Why not try each candidate in turn and choose the one that
throws the least?

I have found a workaround. By making some small artificial changes (notice
a pattern?) to one method that makes its signature less readable I can
affect changes in which rounds each method participates. This allows things
to compile but I lose some useful information about which lambdas actually
don't throw exceptions. I have found a lot of variations  to choose from
but not the one that produces the optimal result so far.

I'd like the compiler to choose the optimal method automatically, because
it knows the types better than I do.  Absent that, I'd like it to give each
method its due consideration, because that's why I added the overloads in
the first place. Absent that, I'd like some API for saying which order the
overloaded methods should be tried. And absent that, I'd like to have some
official documentation on how to correctly target methods to a particular
round of resolution.

Could I have one of those, please?





Sent from my Windows Phone


More information about the lambda-dev mailing list