I wonder why this is desirable. A type instability in the array type is
unlikely to be of much concern, because the cost of array operations will
wildly overshadow the cost of a dynamic dispatch. Once the array passes a
function barrier, its eltype becomes inferrable. A type instability in a
scalar type, on the other hand, is a huge performance trap.
On Saturday, September 17, 2016 at 6:22:36 AM UTC-4, Pablo Zubieta wrote:
>
> There is a bit of a conflict between elementwise operations and broadcast
> (both rely on promote_op). There has been issues on the past where people
> wanted things like
>
> 1 .+ Number[1, 2, 3] == Number[2, 3, 4]
>
> to work. The current behaviour is consistent with this, which is, if you
> start with a non-concrete container type, it tries to preserve the general
> container type. This works, except for Any. For Any it builds the array
> using the types of each value. The option to have more consistency would be
> to have different promotions mechanisms for broadcast and elementwise unary
> and binary operations.
>
