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.

Reply via email to