I've seen the same, and the answer I got at the JuliaLang gitter channel was that it could not be inferred because r could be of length 0, and in that case, the return type could not be inferred. My Julia-fu is too weak to then explain why the comprehension would be able to infer the return type.
On Thursday, September 22, 2016 at 9:27:37 PM UTC+2, Stefan Karpinski wrote: > > I see the same, yet: > > julia> r = rand(10^5); > > julia> @time test1(r) > 0.000246 seconds (7 allocations: 208 bytes) > 33375.54531253989 > > julia> @time test2(r) > 0.001029 seconds (7 allocations: 781.500 KB) > 33375.54531253966 > > > So test1 is efficient, despite the codewarn output. Not sure what's up. > > On Thu, Sep 22, 2016 at 2:21 PM, Christoph Ortner <christop...@gmail.com > <javascript:>> wrote: > >> I hope that there is something I am missing, or making a mistake in the >> following example: >> >> r = rand(10) >> test1(r) = sum( t^2 for t in r ) >> test2(r)= sum( [t^2 for t in r] ) >> @code_warntype test1(r) # return type Any is inferred >> @code_warntype test2(r) # return type Float64 is inferred >> >> >> This caused a problem for me, beyond execution speed: I used a generator >> to create the elements for a comprehension, since the type was not inferred >> the zero-element could not be created. >> >> Is this a known issue? >> > >
