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. On Wed, Jun 4, 2014 at 10:09 AM, Andrew Simper <[email protected]> wrote: > Thankyou very much for pointing that out, it was not obvious to me what > was going on! > > I would have expected if I just wrote int64(4) as the last line would > return that value, but if an assignment was deliberately done by the coder > I expected it would be honoured and then the left hand side would be > returned. Regardless I am very glad to hear that the type of y stayed put > as Float64, which is a much more important issue. > > > <https://lh5.googleusercontent.com/-TxT5cf6TxHE/U48oBF4ZyuI/AAAAAAAAAN0/NhaVccM28DE/s1600/Screen+Shot+2014-06-04+at+10.06.36+PM.png> > > > > On Wednesday, June 4, 2014 1:28:50 PM UTC+8, Stefan Karpinski wrote: > >> The expression y = int64(4) returns its right hand side, not the value of >> y. If you add an explicit `return y` after that, it does what you expect. >> >> >> On Wed, Jun 4, 2014 at 1:22 AM, Andrew Simper <[email protected]> >> wrote: >> >>> All good here, you were polite and to the point and it is easy to work >>> around. Basically I took from the replies: >>> >>> Jameson: that is a redundant thing to do since that case is already >>> handled another way >>> Stefan: yes, but it is inconsistent since inside functions this same >>> syntax is recommended for efficiency so we should really fix this when we >>> have time >>> >>> Ok, I think I've found the problem of my confusion, and it stems from my >>> interpretation of this document: >>> >>> http://julia.readthedocs.org/en/latest/manual/types/ >>> >>> When appended to a *variable* in a statement context, the :: operator >>> means something a bit different: it declares the variable to always >>> have the specified type, like a type declaration in a statically-typed >>> language such as C. Every value assigned to the variable will be >>> converted to the declared type using the convert function: >>> >>> But "always" seems like too strong a word to use (at least not as of >>> v0.3.x) since this happens: >>> >>> >>> <https://lh6.googleusercontent.com/-k6nxq7zpvIY/U46ZDhgBY3I/AAAAAAAAANQ/dVF1AIH0s_0/s1600/Screen+Shot+2014-06-04+at+11.53.32+AM.png> >>> So with this type of behaviour I can see why using the ::Float64 type >>> definition at the global scope is problematic, since at any time anyone >>> could change the type, whereas in the local scope you know all the >>> operations on the variable and the order they are happening in so you know >>> at each line what the type will be. >>> >>> What is the use case of locking down the type to something temporarily >>> and then allowing it to be changed it again? This could lead to all sorts >>> of programmer errors. If there is such a use case then is there another way >>> to handle it? If the type of a variable declared with syntax ::TypeName is >>> locked down from changing then such declarations done globally could be >>> more easily handled, and local declarations could be more aggressively and >>> easily optimised as well since the compiler knows they will always refer to >>> a fixed type. >>> >>> >>> >>> >>> On Wednesday, June 4, 2014 11:18:48 AM UTC+8, Stefan Karpinski wrote: >>> >>>> I hope you didn't interpret that as dismissive – it would be good to >>>> have this fixed. >>>> >>>> >>>> On Tue, Jun 3, 2014 at 11:09 PM, Andrew Simper <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On Wednesday, June 4, 2014 10:32:43 AM UTC+8, Stefan Karpinski wrote: >>>>>> >>>>>> I do think it would be a good thing to fix, however. It's just not as >>>>>> pressing as other issues. >>>>>> >>>>>> >>>>> Yep, I completely understand, please get on with the more important >>>>> stuff. >>>>> >>>>> Hopefully any other c / c++ programmers will get to read this thread >>>>> and not have to interrupt you again about this quirk. >>>>> >>>> >>>> >>
