The plan is to make the type of a comprehension (and map, etc.) independent of type inference and instead produce an array of the same element type as you would get if you wrote out an array literal with those values: https://github.com/JuliaLang/julia/issues/7258. There are some tricky details to nail down, such as what to do when the array is empty. This is tricky since you want the comprehension construct to be type stable but you have no values by which to determine the element type of the array should be. In fact, I'm generally a bit concerned about the impact on type stability dues to this change.
On Mon, Mar 23, 2015 at 2:56 PM, Uliano Guerrini <[email protected]> wrote: > Ok thank you for the clarification, now I see how it can be done. Still I > think that would be better prevent such "unlikely ugliness" in order to > have a behaviour more symmetric and closer to "naive user" expectancies > (that’s me). > > Il giorno 23/mar/2015, alle ore 14:47, Stefan Karpinski < > [email protected]> ha scritto: > > Consider the following: > > julia> k=[-1.0,0.0,2.0] > 3-element Array{Float64,1}: > -1.0 > 0.0 > 2.0 > > julia> pow(a,b) = (global k=["foo","bar","baz"]; ^(a,b)) > pow (generic function with 1 method) > > julia> [pow(k[r],c-1) for r=1:3,c=1:3] > 3x3 Array{Any,2}: > 1.0 "foo" "foofoo" > "" "bar" "barbar" > "" "baz" "bazbaz" > > > There are no threads or coroutines – a function invoked by the > comprehension reassigns a global that the comprehension depends on. Of > course, this is an awful thing to do, but it's perfectly possible. Since ^ > is just a normal function that happens to be defined when you start up > julia, the same thing could happen when it's called. > >
