Remove ::Function restrictions?

[tkf]

Re:

ThreadPools.jl/src/interface.jl

Lines 9 to 10 in 943e831

	pforeach(pool, fn::Function, itr)
	pforeach(fn::Function, pool, itr)

ThreadPools.jl/src/interface.jl

Lines 47 to 48 in 943e831

	pmap(pool, fn::Function, itr)
	pmap(fn::Function, pool, itr)

I'd suggest removing the restriction ::Function from pforeach(fn::Function, pool, itr) etc. since any object in Julia can be a callable. For relevant discussions, see JuliaLang/julia#34296 and JuliaLang/julia#30382. I think this comment by JeffBezanson is a nice summary (emphasis by me):

With multiple dispatch, just as the meaning of a function is important to get consistent, it's also important to get the meanings of the argument slots consistent when possible. It's not ideal for a function to treat an argument in a fundamentally different way based on its type: e.g. "if this is a Function, then call it on pairs of values, otherwise assume it's a container providing the values to use".

This makes having pforeach(pool, fn::Function, itr) a bit an uneasy choice. I think deprecating this method in 1.1 is a reasonable choice.

[tro3]

This one fell off my radar when I got busy the last few months. I am okay with the above, but how would the compiler differentiate pforeach(pool, fn::Function, itr) from pforeach(fn::Function, pool, itr)? I suppose pool could be typed.

[tkf]

Dispatching on a pool type sounds good to me. But this is tricky so that's why I recommended deprecating pforeach(pool, fn, itr). It's also what Jeff's comment is all about.