Assignment expressions always return the right hand side, not the left hand side, so that chaining assignments don't produce weird results doing something like
y = v[i] = x With this rule, this is always equivalent to doing y = x; v[i] = x (and the order doesn't matter). If assignment returned the left hand side, then it would be equivalent to v[i] = x; y = v[i]. So in the first version, you're getting the result of [fun(i) for i = 1:3], not the value that gets assigned to A. On Wed, Oct 29, 2014 at 1:57 PM, Zenna Tavares <[email protected]> wrote: > Ok, but then why does it return the Vector{Any}. The following two > functions give different results > > function makestring(fun) > A::Array{ASCIIString} = [fun(i) for i = 1:3] > end > > > function makestring(fun) > A::Array{ASCIIString} = [fun(i) for i = 1:3] > convert(Array{ASCIIString},A) > end > > I thought maybe it was a weird REPL thing, but it's not. > > On Wednesday, October 29, 2014 1:52:01 PM UTC-4, John Myles White wrote: >> >> I'm pretty sure this sort of thing always works since type declarations >> on variables behave like convert calls: >> >> julia> function foo() >> a::Int64 = 0x01 >> return a >> end >> foo (generic function with 1 method) >> >> julia> foo() >> 1 >> >> -- John >> >> On Oct 29, 2014, at 10:50 AM, Zenna Tavares <[email protected]> wrote: >> >> > Also, the following runs but still returns a Vector{Any}. How is this >> possible? >> > >> > function makestring(fun) >> > A::Array{ASCIIString} = [fun(i) for i = 1:3] >> > end >> > >> > >> > On Wednesday, October 29, 2014 1:45:51 PM UTC-4, Zenna Tavares wrote: >> > As shown in the following example, I am getting differently typed >> arrays depending on where I use the list comprehension. >> > >> > f(i) = "$i" >> > A = [f(i) for i = 1:3] >> > function makestring(fun) >> > A = [fun(i) for i = 1:3] >> > end >> > B = makestring(f) >> > >> > In this example A has type Vector{ASCIIString} while B has type >> Vector{Any}. What gives? And is there a workaround such that we get a more >> specific type? >> > >> > I understand there are some open issues related to this, but I am not >> sure if this case comes under what's already been discussed. >> > >> > >> >>
