You could expand x = y = expr as tmp = expr y = tmp x = tmp
That way expr is only evaluated once (not a concern when it's a literal) and the value assigned to x doesn't depend on y in any way. On Thu, Jun 5, 2014 at 11:00 PM, Andrew Simper <[email protected]> wrote: > Ok, thanks for explaining that, that makes lots more sense but to me is > not immediately obvious, I would have expected the type of x in f2 to > change to Float64 as the chained expression was evaluated from right to > left, so the consequence of this not happening is unexpected for me! I > don't think one is better or worse than the other as long as it is > consistent for the language, now I know what happens I can avoid using them > when I want something different to happen. > > For clarity can you please let me know that this is the right > interpretation for what happens in a chained expression? > > function f2() > y::Float64 > > # the chained assignment below results in the equivalent of (but the > order may be different) > # x = 0 > # y = 0 > # return 0 > > x = y = 0 > > end > > > > > On Thursday, June 5, 2014 12:32:03 AM UTC+8, Stefan Karpinski wrote: >> >> The reason that assignments return the unconverted value of their right >> hand side is so that assignment chains behave as expected instead of the >> assignments to the right subtly and surprisingly affecting assignments to >> the left. Otherwise you would have unfortunate effects like this: >> >> function f1() >> x = y = 0 >> return x >> end >> >> function f2() >> y::Float64 >> x = y = 0 >> return x >> end >> >> julia> f1() >> 0 >> >> julia> f2() >> 0.0 >> >> >> This is NOT what currently happens – these return the same value, i.e. 0 >> – this is a mockup of what would happen if the expression y = 0 evaluated >> to the value that is assigned to y after conversion rather than the value 0 >> before conversion. >> >>
