New *(::Bool, ::Number) definition generates conflicts with other Number types

[jwmerrill]

efcb565 introduced a *(::Bool, ::Number) method. This conflicts with definitions of the form

*{T<:Number}(::Real, ::T)

which I suspect most custom number types define. PowerSeries.jl for one has lots of newly conflicting definitions now.

Are there alternative possibilities for implementing whatever feature efcb565 is implementing? Should all Number types have to disambiguate themselves with Bool?

[mlubin]

This also caused a conflict for DualNumbers.

[toivoh]

I thought that this kind of thing should generally be handled with promote_type; you just can't define n_n methods of the _function for all possible combinations of lhs and rhs. Since it was decided to makefalsea strong zero,promote_type is not enough for that particular case, however.

[jwmerrill]

Custom number types often define special * definitions that could in principle be handled by promotion for performance. Complex does it, and I bet rational does too. That's why I do it in PowerSeries.

Complex had to get two new * definitions to disambiguate with Bool in efcb565.

[quinnj]

It looks like both packages affected here have resolved the ambiguities without too much hassle. Please reopen if something does need to be changed.