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. >
