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] > <javascript:>> 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. >>>> >>> >>> >
