change whicht to return rather than call show

[WestleyArgentum]

I would argue this is more useful. When run in the repl the returned value will be shown nicely, when run elsewhere the result can be used.

[stevengj]

As I noted in #5467, this makes which non type-stable, because it returns a Method if one is found and nothing otherwise. Maybe it should throw a MethodError instead if nothing is found?

[WestleyArgentum]

I apologize, I meant to reference that issue and #5464. Late night, tired.

I'm not sure I have a good sense of how important type-stability is, but part of me likes checking for nothing more than catching an error. Is there a cost to introducing exception handling? Would that outweigh the performance gained from type-stability?

[stevengj]

I suspect that at least some of the code that would use which in a programmatic way would use it in the case where a method is assumed to exist, so they won't check for an exception at all ... they will just let the exception propagate upward if it is thrown. In which case it is more convenient (and possibly faster) to use an exception to signal a lack of a method.

But I doubt that performance is really an issue for realistic uses of this function. Conceptually, it seems cleaner to me to use an exception to signal an exceptional condition from a function that normally returns a Method, rather than a sentinel value (nothing).

However, I don't have strong feelings about this. @StefanKarpinski?

[WestleyArgentum]

^ good points, I could see either way working

[WestleyArgentum]

I'm going to close this and assume that we'll do something more along the lines of #5646

[coveralls]

Changes Unknown when pulling 7a6e0aa on WestleyArgentum:patch-2 into * on JuliaLang:master*.